On 2015-10-29, Scott Kostyshak wrote:
> On Wed, Oct 28, 2015 at 08:52:32PM -0400, Richard Heck wrote:
>> On 10/28/2015 03:52 PM, Scott Kostyshak wrote:
>> >
>> >It seems there are a few different ideas. Let me see if I can summarize
>> >them:
>> >
>> >1. A layout change can be made if it is supported by the current release
>> >of TeX Live and the previous release.
>> I think we have long had an implicit policy like this: Don't break Debian.
>> But we could change the target: Don't break Ubuntu LTS and/or latest Centos.
>> Both of these are conservative without being glacial. I'm not sure how much
>> difference that would make in practice.
...
> I still think there is some use to making the policy well-defined and
> explicit.
I propose to make the oldest supported TeXLive (and maybe MikTeX) version
public for any release.
Older distributions may work but are not guaranteed...
This helps both, developers and users.
...
>> another message.) But shorter term, the solution for now seems to be to make
>> packages that have this kind of change depend upon the version:
>> moderncv-14.layout, etc.
>> Or, perhaps: Update the non-indexed version (so now
>> moderncv.layout works with the current version), but *also* provide the
>> older versions for people who want them.
Proposal:
If we want support for a new version that breaks the old before the new
version reaches the "oldest supported TeXLive" (osTL) for <package>:
1. rename <package>.layout to <package>-<oldversion>.layout
2. create a symbolic link from <package>.layout to
<package>-<oldversion>.layout
3. create <package>-<newversion>.layout
If the osTL is raised to a release including the new version:
1. change the symbolic link from <package>.layout to
<package>-<newversion>.layout
This way,
* nothing breaks for old documents for users with the "osTL" distro,
* users can select between old and new versions, according to their distro
and update practice,
* old layout files can stay under their already introduced name,
* the non-versioned layout keeps moving with TeXLive development.
>> But even if we do that, then I think we should require that the new layout
>> to include preamble code that makes the output with an old package
>> equivalent to that with the new one, at least as far as the new style is
>> concerned. E.g.:
>> \ifundefined\phone{
>> \newcommand\phone{
>> % code borrowed from the new version....
>> }
>> }
>> There's a \providecommand, too, that is equivalent to this, right? Ugly
>> preamble stuff, to be sure, but useful, nonetheless, I think.
As this is ugly, it should only be an alternative if we do *not* fork the
layouts for different versions.
It will be less ugly, if this fallback code is only included if the old
version is detected (however, this could lead to problems with compiling on
another machine...).
>> I spoke to this above. I'll add, though, that there just are differences
>> between class files in this way. Some update very frequently, with lots of
>> changes; with others, updates are usually just bug fixes, with no change to
>> basic functionality. It's the former that causes problems. With the latter,
>> there's no need for version indexing.
I am with Richard here: versioned layouts for all classes and modules are
overkill.
Günter
