Brian Sniffen writes: > >>>>> On Fri, 26 Jul 2002 20:59:23 +0200, Frank Mittelbach <[EMAIL > >>>>> PROTECTED]> said: > > > The point is that by distributing it under LPPL it will be the same > > everywhere (or not on the installation). That work of yours might > > change/overwrite any part of other code in the ULL. That's fine > > because that doesn't change the fundamental property of the ULL > > (identical behaviour as long as you start with a LaTeX kernel at big > > bang). > > How does that work when an author releases a new version of a package? > Surely then (since as has been said before any change will change > output) the output changes.
I should of course have said, "potentially changes the output" since a change in documentation will change nothing in the output and adding a new feature might not change many documents (if any). But in most cases a change affects documents using that work in one way or the other (and usually in subtle ways, and not necessarily in glaring bugs that stop the processing --- which is worse as such changes are caught often too late). But i don't want to chicken out here. changes affects documents so when some author releases a new version of his/her package that potentially results in incompatibilities with existing documents (and less often in bugs that need fixing). Now how does that work in the TeX world? Not perfectly but more or less it does. First of all, true compatibility backward and forward can only be achived by no change at all, even adding only features would potentially break existing documents and since there is no clearly defined boundary between internal and external interfaces and code in a macro language any code change might trip another package that overwrites part of the code of one package but uses other parts of it (it is like a CVS merge from overlapping modifications, only that the conflict isn't noticeable directly in all cases). So what happens? First of all TeX as such together with its "plain" format and its Computer Modern fonts is an absolute fix point, ie documents running only on top of this will behave identically and now and in the future. (this is partly due to the lucky situation that TeX is virtually bug free by now, otherwise even that statement wouldn't be correct). For TeX variants that situation is less stable, ie they evolve, so if you use LaTeX on top of pdftex then already pdftex might change over time, but at a given point in time you have cross-installation identity. Now for LaTeX ... Because for reasons of stability the kernel itself doesn't change much if at all (these days). As a policy, for example, we don't change article.cls to improve its layout (even though its layout leaves much room for improvment:-) Simply because there are several hundred thousands (if not millions) of documents out there that are based on article.cls either directly or indirectly by using another class that loads article and modifies it. So we promote that people provide better classes but keep this as a good basis to build upon. We also promote kernel changes being done in this way, ie distributed as packages. This way improvements, new code different layouts can be applied for current documents (if desired) but will not affect older documents that worked around that problem or layout misfeature, or whatever in some way already and would probably choke on the changed kernel code. There are a number of packages out these days that extend the kernel with important features, like hyper-reference support, a better two-column mode, you name it. If any of such packages would have been added to the kernel it would break a lot of existing documents but this way it doesn't break anything. The very major packages often apply a similar attitude, though perhaps less rigerously, eg the big rewrite of the AMS math support was done my keeping amstex.sty and providing amsmath.sty instead. Why was it done this way? by cause AMS has its own commitment to a huge archive of documents and to its users (the math community) However, amsmath has undergone revision and bug fixes and probably has tripped one or the other document this way. But even so, the important point in all that is that at any given point in time, documents could be exchanged between authors and other authors as well as between the authors and the publishers, because the it was part of ULL so everybody with a recent LaTeX installation had the same amsmath. Now if you get to the outskirts of the ULL, eg smaller packages, more specialized packages, as well as "new" packages, then you often find more drastical changes --- most people welcome this as a means of stablising stuff and getting better quality, even though it means that documents using such packages may need minor corrections if you rerun them after a while using new LaTeX distributions. For example, the geometry package, just went from version 2x to 3y (with the bug fix number after 3 rapidly changing :-). It actually turned its interface upside down, though Hideo tried to be as compatible as possible (basically because his 2x version already had a good number of users). What he did was to provide one option to version 3 that would make it start with the 2x defaults. So yes, if you used that package in the past your documents would now change and to get the old behaviour back you have to add the compatibility option into your old documents. But the point again is --- the exchangibility is not affected. Other package writer work differently, sometimes they fork, sometimes they just hope that they are doing such a tiny change that clearly nothing could ever break (and usually they find out that they are wrong :-) So to summarizes: the more packages (ie independed works within the ULL or outside ULL but in LL) you use the bigger the chances that your document is not going to work without some helping and fixing at some point in the future. So the claim that Boris (or somebody else) made that LPPL is ensuring absolute backward compatibility is not true. It does help a good deal, by ensuring that a package if not forked to a different name has a single updating path but that that in alone is no guarantee. As closer as you get to the required part of the ULL the better the chances are that you have compatibility over a long time and in practice it works out well enough. The main goal of LPPL is to make the ULL a cross platform identity (if you chose to work with a latex kernel as a starting point!) at a given point in time (and normally over a longer time range in fact). It helps on the with the backward compatibilty but that's not its primary purpose. I recently tried to rerun "The LaTeX Companion" which is using 170 packages or so (not written by me) and it took me about a day to get that beast producing more or less decent output again and that as you can imagine is a rather uncommon testing case. frank -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]