On Mon, Oct 26, 2015 at 09:16:03PM +0100, Georg Baum wrote: > Uwe Stöhr wrote: > > > Am 26.10.2015 um 06:31 schrieb Scott Kostyshak: > > > >>> I think it is safe enough to support 2 years old features and would > >>> therefore like to put it in. > >> > >> Do we have any policy on this? What have we done in the past? > > > > No strict one, but the feature should be at least in the current and > > previous TeXLive as far as I remember. > > This is be the case here. > > If everybody agrees with this policy then we should document it. I would > also add that we can be less strict if the only change is an added style, > but the layout file would still work with older versions of the package if > the style is not used. Then users who do not have the latest versions can > simply stick to the styles supported by the old version, but if the syntax > of an existing stely or some preamble code changes then the new layout file > would always require the new package.
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 ? 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) 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. It seems we could combine all 3 in some way. For example, we could enforce both (1) and (2) (whichever is more binding). Then, instead of just updating the file we create versions, thus implementing (3). In other words, I think that even if we go with (3) there is still a necessity to do (1) and/or (2) because we do not want the .lyx file of users to suddenly not compile (even if all they need to do is to swich the class). Scott
