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. 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.
Thanks for the explanation. All of what you wrote makes sense to me.
> >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.
I still think there is some use to making the policy well-defined and
explicit.
> >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.
OK.
Scott
