Received: by nummer-3.proteosys id <01C19443.A196065C@nummer-3.proteosys>; Thu, 3 Jan 2002 11:44:33 +0100 Return-Path: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C19443.A196065C" 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]) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Subject: {1} Transition from LaTeX 2.09 to LaTeX 3.0 Date: Wed, 18 Mar 1992 14:06:33 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: From: Sender: "LaTeX-L Mailing list" To: "Multiple recipients of" Reply-To: "LaTeX-L Mailing list" Status: R X-Status: X-Keywords: X-UID: 622 This is a multi-part message in MIME format. ------_=_NextPart_001_01C19443.A196065C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Various people have various bright ideas about the form that LaTeX 3 = might take. Unfortunately, the project is being done on a voluntary basis, = with hardly any funding, and with finite personnel. Is there anything to be said for not worrying too much about providing a compatibility module for LaTeX 2.09? It would be one less thing to = do. At our computing centre, we are often in the position of introducing = new, improved versions of applications software that are incompatible with previous versions. This happens, for example, with: * SPSS, where between certain major releases, end-users have had to = learn to change the instructions they give to the package. (In practice, = we might make both the old release and the new release available via = different commands for 12 months or so, so that end-users don't have to change immediately.) * NAG Library, where a routine and its replacement may overlap for a year or two, but eventually end-users have to change their programs = to call the new routine. I think it also happened with BibTeX, where version 0.98 .bst files = wouldn't work with version 0.99. One scenario would be to: * "freeze" LaTeX 2.09 (and all its associated style-files etc.) when LaTeX 3.0 is ready * keep the frozen LaTeX 2.09 etc. in archives for a further 2 years or = so * recommend that end-user sites make LaTeX 2.09 available via a latex209 command, and LaTeX 3.0 available via a latex command for a similar (2 years or so) overlap period. I assume that the main thing would be that latex209 would need TEXINPUTS set to search for LaTeX 2.09 .sty files etc., with the 2.09 lplain.fmt selected, while latex would need TEXINPUTS set to search for LaTeX 3.0 files, and the LaTeX = 3.0 .fmt file used. * tell anybody who doesn't like this that "no-one is stopping you from keeping LaTeX 2.09 going in its frozen state for as long as you like". This scenario might give "the project team" one less thing to do than = the "provide a LaTeX 2.09 compatibility module for LaTeX 3.0" scenario. = Might it be better to spend the finite time that is available looking to the future than trying to be compatible with the past? David Rhead JANET: d.rhead@uk.ac.nottingham.ccc.vme ------_=_NextPart_001_01C19443.A196065C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable {1} Transition from LaTeX 2.09 to LaTeX 3.0

Various people have various bright ideas about the = form that LaTeX 3 might
take.  Unfortunately, the project is being done = on a voluntary basis, with
hardly any funding, and with finite personnel.

Is there anything to be said for not worrying too much = about providing
a compatibility module for LaTeX 2.09?  It would = be one less thing to do.

At our computing centre, we are often in the position = of introducing new,
improved versions of applications software that are = incompatible with
previous versions.  This happens, for example, = with:
*  SPSS, where between certain major releases, = end-users have had to learn
   to change the instructions they give to = the package.  (In practice, we
   might make both the old release and the = new release available via different
   commands for 12 months or so, so that = end-users don't have to change
   immediately.)
*  NAG Library, where a routine and its = replacement may overlap for
   a year or two, but eventually end-users = have to change their programs to
   call the new routine.
I think it also happened with BibTeX, where version = 0.98 .bst files wouldn't
work with version 0.99.

One scenario would be to:
* "freeze" LaTeX 2.09 (and all its = associated style-files etc.) when
  LaTeX 3.0 is ready
* keep the frozen LaTeX 2.09 etc. in archives for a = further 2 years or so
* recommend that end-user sites make LaTeX 2.09 = available via a
     latex209
  command, and LaTeX 3.0 available via a
     latex
  command for a similar (2 years or so) overlap = period.  I assume that
  the main thing would be that
     latex209
  would need TEXINPUTS set to search for LaTeX = 2.09 .sty files etc.,
  with the 2.09 lplain.fmt selected, = while
     latex
  would need TEXINPUTS set to search for LaTeX = 3.0 files, and the LaTeX 3.0
  .fmt file used.
* tell anybody who doesn't like this that = "no-one is stopping you from
  keeping LaTeX 2.09 going in its frozen state = for as long as you like".

This scenario might give "the project team" = one less thing to do than the
"provide a LaTeX 2.09 compatibility module for = LaTeX 3.0" scenario.  Might
it be better to spend the finite time that is = available looking to the
future than trying to be compatible with the = past?


David Rhead
JANET: d.rhead@uk.ac.nottingham.ccc.vme

------_=_NextPart_001_01C19443.A196065C--