It seems to me that, despite Guenter's recent change of mind, there is a clear majority in favor of the policy that was proposed some time ago, discussed on the list, and then documented, in draft form, in Development.lyx, namely:
> Every now and then, there are changes to LaTeX document classes that > break backwards compatibility.Reasons can be a new name for the > |*.cls| file, removed LaTeX commands, or both. How should this best be > handled in LyX? > The idea is to support the new version with a new LyX layout so that: > > * Existing documents can still be opened in LyX and will continue to > work on systems where the old version is still installed. > * With differently named |*.cls| files, LyX can check for the > availability of the particular version and reflect this in the > GUI. Different document class versions with the same file name are > currently (2.2.x) not detected by the configuration script. This > is planned for 2.3. > > https://www.mail-archive.com/[email protected]/msg192467.html > However, what we really need is version detection for the > configuration, so that the user can be warned if the required > class file has the wrong version. (If the class file keeps the > name over the version change, only one of the two layout files > generates compilable documents.) > This point was also made here: > http://permalink.gmane.org/gmane.editors.lyx.devel/143798 > * The new layout can be added both to the master and the stable > branches, in accord with the policy discussed in section 3.1. No > lyx2lyx conversion is then required when a new major version is > released. > > The user can move an existing document to the new version simply by > selecting a new document class. This step is well supported by LyX, > with established methods for handling unsupported styles and other > changes. This way, no lyx2lyx code is required. > LyX Document I agree with Uwe that we have been discussing this for too long. I personally don't see that enough rides on this to continue debating it. There are arguments to be made on both sides, but we need to make a decision for the 2.2.x cycle, since this issue is bound to come up again. I therefore propose that we go with what is in Development.lyx, since it seems clear, to me, that this is what most people with a stake in this decision support. If we need to take a formal vote, then let's do that. Richard
