On Wed, Apr 06, 2016 at 10:37:00PM -0400, Richard Heck wrote: > > 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/lyx-devel@lists.lyx.org/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.
I agree. I actually don't think there is a need for a vote because the majority of those who took part in the discussion prefer for a new layout file. I'm glad that we took the time to discuss this issue (and we have been working out other 2.2.0 issues in the meantime anyway) and I think we made progress, but I agree it is time to move on. Scott
signature.asc
Description: PGP signature
