On 2016-03-25, Richard Heck wrote: > On 03/25/2016 02:34 AM, Scott Kostyshak wrote:
>> 3. The LaTeX class file associated with the layout have been updated. >> (3) is the most complicated case and the rest of this discussion is >> focused on it. We can break down (3) further: >> 3a. The updated class or style files are named differently. ... >> In master, since we will have multiple layouts, we should move the >> common parts of the old and new layout files into a .inc file that is >> included in both layout files. In most cases, it will be simpler just to include and modify the existing *.layout file. (Mind, you can also "Input" other layout files, e.g. "dinbrief.layout" is based on "letter.layout".) >> In the example (#10027), the new layout name would be aastex6.layout >> and the new template name would be aastex6.lyx. As the package name on CTAN is still "aastex" (http://www.ctan.org/pkg/aastex), the template could also keep the package name (but call the new document class file). a) There is no reason to provide a template for an obsoleted document class. b) Updating the existing template will not break any existing documents. c) Users with the obsolete documentclass will realise that they need to update before trying to commit their article to the paper. >> Once we have a new template, the old template (but not layout file) >> should be removed in master, but not in branch. If the old *.cls file is clearly stated as obsoleted, we should update the template also in branch: a) There is no reason to provide a template for an obsoleted document class. ... > I don't myself see why we shouldn't add the new layout file, which is > this case is completely new, to branch. ... Seconded. Both, master and branch could provide both layout files and an updated template. >> 3b. The .cls file has been updated but uses the same name. ... >> 3bii. It is not just that new styles have been added. >> Suppose that there is a class file with the same name and with two >> incompatible versions, say foo.cls v1 and foo.cls v2. Suppose that LyX >> supported v1 with a layout called foo.layout. In master we should add >> support for v2, calling it foo.layout but still support the old one by >> copying the old foo.layout file to foo1.layout. The file >> templates/foo.lyx in master should be updated to use the new layout >> (foo.layout). This becomes simpler, if we use the new name for the new layout: +1 no need for a file format change +1 no need for lyx2lyx code +1 users of stable/branch can manually install the new layout -1 the "generic" layout name points to an obsolete version. A common naming of the layout files in branch and master simplifies both, implementation and understanding of the scheme. This is IMO more important than having the "short and generic" name for the current layout. >> Similar to the case of (3a), we can have a .inc file that contains the >> shared code between foo.layout and foo1.layout. Again, there is no need for an inc file. Rather the new layout can Input and modify the old (or vice versa). ... > This all seems reasonable to me. But it leaves open the most contentious > issue: What to do about this in stable? Uwe's concern is always that, if > we don't do anything, then it's impossible to use LyX to produce papers > you can submit to journals that require the new class file. Unless, of > course, you write your own layout file. That does not seem like a good > situation. This sort of thing could happen two days after 2.2.0 is > released. The problem on the other side is that simply updating the > layout file breaks the files of people (or journals) that are still > using the old version. > I see a number of options. > (1) Just post a new layout file on the wiki and people can get it from > there. That's not an unreasonable solution, though I'm not sure people > know about the wiki so much. Then again, what is likely to happen is > that people start getting LaTeX errors with an updated version of the > class file, and then hopefully they ask on the list. > So this isn't terrible, but I think we can do better. > (2) Handle this in stable inversely to how we handle it in master. ... > (3) All the changes needed to go from the old version of the layout file > to the new one could surely be encapsulated in a module, ... LyX modules are for features/extensions that can be used with (almost) all document classes. (Generally, a LyX module corresponds to a *.sty LaTeX package while a LyX layout corresponds to a *.cls LaTeX document class.) Using a module for versioning of a specific document class would blur this distinction and clutter the list of modules with very rarely used ones. Therefore, I prefer: (4) Keep the old (generic) layout name for the obsolete layout. Add a new layout with "versioned name". (The new layout can "Input" the old one and overwrite, obsolete and remove changed styles.) - no change for old documents in branch and master. - users with the old LaTeX class file can compile without change, - users with the new LaTeX class file will have to manually change the document class (and adapt existing documents) if they want to re-compile. As there is no file format change, a maintenance release could also provide an updated template, so that new documents will not be based on the obsoleted LaTeX class file. > But it seems to me that a better long-term solution would be: >> ***1 class version detection ... > That handles all the problems here, and I propose to make implementing > this my first job for 2.3. This would be very nice. Thanks, Günter
