On 2016-03-28, Georg Baum wrote: > Guenter Milde wrote: >> On 2016-03-25, Richard Heck wrote: >>> On 03/25/2016 02:34 AM, Scott Kostyshak wrote:
>>>> 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). > I don't think we should look at the package name, since this does not work > for packagews containing more than one class (e.g. > http://www.ctan.org/pkg/koma-script). I tend to be more pragmatic here: the aastex package contains just one document class: this used to be aastex.cls, now it is aastex6.cls. IMO: * the layout file for aastex6.cls *must* be aastex6.layout * the template file (replacing the old templates/aastex.lyx) may be called either aastex6.lyx or aastex.lyx. >> 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. > Agreed to a) and b). >> c) Users with the obsolete documentclass will realise that they need to >> update before trying to commit their article to the paper. > How? There is no connection to the template anymore once the document is > created. OK, I have to clarify the limitations: "if we update the template to use the new document class version, >> c) Users with the obsolete documentclass will realise that they need to >> update before trying to commit their article to the paper. But if we keep the old template, these users will not realize that they need to update the document class." >>>> 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: > Yes, if we decide that a new layout file is not a file format change we > should do that. If a new layout file is a file format change then we can't > do that. >>>> 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. > I disagree. IMO, it is more important to have a consistency between current > .layout and current .cls file. This does also reduce possible future > namespace conflicts. The needed lyx2lyx changes are trivial, and could even > be implemented in a generic helper function. However, the changes would require a file format change. (Not a problem, if a new layout requires a file format change anyway but I prefer it not to...) Günter
