Dear all, On 2016-04-06, Richard Heck wrote: > On 04/05/2016 06:15 PM, Scott Kostyshak wrote: >> On Tue, Apr 05, 2016 at 10:41:42PM +0200, Georg Baum wrote: >>> Guenter Milde wrote:
>>>> This point (do we allow a new layout version when there is no change in >>>> the *.cls file name) was still not settled. >>> Now I am confused. >> Me too. > Me three. What was committed to Development.lyx says that we should use > a new layout, and although that was written by Guenter it was based upon > what I had thought we had agreed. I consider section 3 "New layouts and modules" still a draft. The note This section is currently only a proposal under discussion. Please correct/amend as suited. Remove this note once a consensus is found. is still there. We settled the question Is the addition of a new .layout file a file format change or not? but left open the handling of case 3b. The .cls file has been updated but uses the same name. There was well based objection to the proposal of a new version-layout by Georg in http://permalink.gmane.org/gmane.editors.lyx.devel/161202 from 28 March: Before discussing the case of incompatible versions with the same name further, I'd like to see an example where we would really need to backport a layout file for the new version to the stable branch, and where the existing mechanism for new styles does not work. My claim is that this case does not happen in practice, ... ... In all cases we discussed in the past, [...] it was possible to use LyX to submit to journals that published a newer version of the .cls file, for one of the following reasons: - The submission required a PDF file, not a .tex file. This is usually the case for the journals that offer both MS Word and LaTeX templates, but many others as well. In this case it does not matter if some styles are renamed. - In case of AGU, you simply needed to skip some obsolete styles. - There were only minor changes, and you would need a few ERT insets, but could write 99% of your paper using the existing styles. My original response was that "acmsiggraph" is an example really requiring a new layout. Working on the layout(s) for "acmsiggraph" I realized that it is possible to handle this with the old layout file in stable: - you simply needed to skip some obsolete styles. Eventually, this can be communicated to the user with updated labels and grouping them in Category Obsolete. (This would be a non-critical update, if backporting new label strings is allowed). - You need a few ERT insets, but can write 95% of your paper using the existing styles. For acmsiggraph v. 96 * you need ERT anyway, because the journal's formatting rules require you to insert LaTeX code generated by a web page. * most of the new styles translate to simple LaTeX commmands without arguments (there should be no content in the paragraphs using them). As a consequence, an updated example file should suffice for stable/branch. I am sorry for the confusion. Now the question remains: After the new consensus, that a new layout does not require a file format change, a) do we want to allow new layouts if a *.cls file has been updated but uses the same name? +n1 allows fast support for the new version without file format change. +1 some ERT or local styles required in stable -1 no automatic provision of new styles for existing documents. Instead, the user must be aware of the new document class and change it manually. -n2 obsolete layout file in lib/, obsolete document class in the GUI or file format change for removed layout and renaming of the new layout. b) do we want to handle this case with an updated layout in master, backporting to stable via "ForceLocal" (see Development 2.6) The decision depends on your personal values for n1 and n2 and advantages/disadvantages missing in my list. My current personal impression is, that acmsiggraph does not merit a new versioned layout - if we agree to clean up cruft at some stage, we need a file format change anyway and n1 \simeq n2. Günter Günter
