Received: by nummer-3.proteosys id <01C19443.A2B3CC44@nummer-3.proteosys>; Thu, 3 Jan 2002 11:44:35 +0100 In-Reply-To: <01GHW8EYAEOWBJSIOJ@MATH.AMS.COM> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C19443.A2B3CC44" Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.5 x-vm-v5-data: ([nil nil nil nil nil nil nil nil nil][nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil]) Content-class: urn:content-classes:message Subject: {3} Re: {2} Transition from LaTeX 2.09 to LaTeX 3.0 Date: Sat, 21 Mar 1992 21:00:44 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "bbeeton" Sender: "LaTeX-L Mailing list" To: "Multiple recipients of" Reply-To: "LaTeX-L Mailing list" Status: R X-Status: X-Keywords: X-UID: 633 This is a multi-part message in MIME format. ------_=_NextPart_001_01C19443.A2B3CC44 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable i'd like to add one more vote to the side of "do it right", regardless of full compatibility with 2.09. i hasten to add that this is my own opinion, not necessarily shared by (others at) the math society (but i haven't asked either). i'd like to comment on upgrading from one version to another in a production environment. there is considerable inertia, for several reasons. first, the delay between initial keying of a manuscript and the return of final proof from the author can be considerable. second, time is needed for testing of production versions of new macros (the in-house versions are not quite the same as what an author sees). and third, the in-house keyboarding staff must be retrained. this is my understanding of how the math society upgraded from amstex 1.x to 2.x. not being directly involved in production, a few details may be askew, but as a similar procedure was followed in an earlier changeover, from an earlier system to tex, i feel on reasonably firm ground. two cutoff dates were set; call them x and y. before x, new work keyed in-house used version 1, but author-prepared manuscripts using either version were acceptable; in fact, authors were encouraged to upgrade as soon as version 2 became available. between x and y, new manuscripts were keyed in-house using version 2, but corrections to any papers keyed earlier continued to be in version 1. as of y, any remaining manuscripts in version 1 were updated to version 2 before publication. if any version 1 document is republished, conversion is expected to be necessary; however, there will be no attempt to convert archival files until there is a particular need. i suspect that a similar approach will be taken when it is time to convert from latex 2.09 to latex3. for the reasons of inertia described above, the two versions may run in parallel for a year or more, but there will be a date after which no new material is keyed using the old conventions, and there will be a (later) date after which the remaining old-style files (now down to a rather small number) will simply be converted, as being less troublesome and/or expensive than maintaining dual systems. the existence of a solid conversion tool could be a positive factor in moving the cutover date earlier in time. i agree with frank that running 2.09 and 3 in parallel indefinitely is a very bad idea. i also agree that a full compatibility style would weaken the incentive to change the input conventions and lead to confusion. so if there really are good reasons for changing something (and i believe there are), i think it best simply to go ahead and make the change -- and to provide good documentation on the nature of the change, how it affects a person doing input, and what are its effects on output. now that rolf lindgren has been "volunteered" to do a survey on the most popular styles and options, could we be reminded of his address so that we can send him our information? -- bb ------_=_NextPart_001_01C19443.A2B3CC44 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable {3} Re: {2} Transition from LaTeX 2.09 to LaTeX 3.0

i'd like to add one more vote to the side of "do = it right", regardless
of full compatibility with 2.09.  i hasten to = add that this is my own
opinion, not necessarily shared by (others at) the = math society (but
i haven't asked either).

i'd like to comment on upgrading from one version to = another in a
production environment.  there is considerable = inertia, for several
reasons.  first, the delay between initial = keying of a manuscript and
the return of final proof from the author can be = considerable.  second,
time is needed for testing of production versions of = new macros (the
in-house versions are not quite the same as what an = author sees).  and
third, the in-house keyboarding staff must be = retrained.

this is my understanding of how the math society = upgraded from amstex
1.x to 2.x.  not being directly involved in = production, a few details
may be askew, but as a similar procedure was followed = in an earlier
changeover, from an earlier system to tex, i feel on = reasonably firm
ground.

two cutoff dates were set; call them x and y.  = before x, new work
keyed in-house used version 1, but author-prepared = manuscripts using
either version were acceptable; in fact, authors were = encouraged to
upgrade as soon as version 2 became available.  = between x and y, new
manuscripts were keyed in-house using version 2, but = corrections to
any papers keyed earlier continued to be in version = 1.  as of y, any
remaining manuscripts in version 1 were updated to = version 2 before
publication.

if any version 1 document is republished, conversion = is expected to be
necessary; however, there will be no attempt to = convert archival files
until there is a particular need.

i suspect that a similar approach will be taken when = it is time to
convert from latex 2.09 to latex3.  for the = reasons of inertia
described above, the two versions may run in parallel = for a year or
more, but there will be a date after which no new = material is keyed
using the old conventions, and there will be a = (later) date after
which the remaining old-style files (now down to a = rather small
number) will simply be converted, as being less = troublesome and/or
expensive than maintaining dual systems.  the = existence of a solid
conversion tool could be a positive factor in moving = the cutover
date earlier in time.

i agree with frank that running 2.09 and 3 in parallel = indefinitely
is a very bad idea.  i also agree that a full = compatibility style
would weaken the incentive to change the input = conventions and lead
to confusion.  so if there really are good = reasons for changing
something (and i believe there are), i think it best = simply to go
ahead and make the change -- and to provide good = documentation on
the nature of the change, how it affects a person = doing input, and
what are its effects on output.

now that rolf lindgren has been = "volunteered" to do a survey on the
most popular styles and options, could we be reminded = of his address
so that we can send him our information?
        =         =         =         =         =         -- bb

------_=_NextPart_001_01C19443.A2B3CC44--