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. This rule can be less strict if
the only change is an added style (so that compilation will not be
broken for older documents). Should we further define "less strict" by
saying that in this case the layout change can be made if it is
supported by the current release of TeX Live ?
If we support the added style, then users who both use that style and
use an older version of the package will have non-compilable documents.
So you could have a document that worked perfectly well, you make one
change---use the new style---and now it won't compile. What follows is a
frustrated message to the user list.
This is the basic problem: The fact that a new style has been added
won't break compilation of existing documents, but it invites users to
create documents that don't compile. There is no easy solution to this,
short of somehow making what styles are available depend upon the
package. Longer term, I think that is clearly the way to go. (I talked
about this a bit in 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.
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.
2. Pavel's idea that for key dependencies such as Qt or TeX we should
look where stable/future versions on major linux distros are. e.g.
stable debian. Another possibility is to look at the current Ubuntu LTS.
If we implement this, we should be specific (e.g. say explicitly Debian
Stable and Ubuntu LTS).
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.
3. Richard's idea to rename the layout file:
"It might be worth renaming the old layout to moderncv-14.layout or
something, in case people don't have the new version."
I don't myself see a reason, when we're dealing with class files like
this one, not to index ALL the layout files to specific versions of
the class file. So we'd have moderncv-14, moderncv-15, etc. The
difficulty is that if we just update moderncv.layout, then people
whose files used to compile just fine now don't compile at all,
because LyX expects some version they don't have. If we at least have
these various versions, then people can switch between them as need
be. We don't do it for them, which will be wrong in some cases.
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.
Richard
