On 2016-04-06, Richard Heck wrote: > On 04/05/2016 01:06 PM, Guenter Milde wrote: >> On 2016-04-05, Richard Heck wrote: >>> On 04/05/2016 04:36 AM, Guenter Milde wrote:
>>> +1 no new document class cluttering the selection list >>> (especially as this is an "exotic" class (not on CTAN, not in TeXLive, >>> ...) >> But this is the point: we are going to build up cruft - obsolete >> layout files and obsolete document classes in the menu without >> pressing need. > I don't see why we will build up anything much. Old versions can be > removed when new major releases are done. And once we have version > detection, the issue disappears, because we don't show all the different > versions. Cls version detection is necessary but not sufficient to secure this. LyX also shows all the obsolete versions where the class file name differs (g-brief, svjour, ...). >>>> +1 no need for *.cls version detection >>> We are going to need this anyway, because of the issues with respect >>> to stable. >> Could you elaborate? (I don't see why this should be different for >> stable and master.) > Because we can't simply update the layout file in stable. That is what > gives rise to this problem in the first place. But this cannot be solved with *.cls version detection, can it? ... > the problem has always been that updating the layout file in stable is > not possible. Backporting is now possible: * new styles can be solved with the ForceLocal -1 flag * old styles can be grouped into Category "Obsolete" I suggest documenting this in Development.lyx >> For the specific case of acmsiggraph ... >> unless someone voluntees to do a ffc, there is time for >> careful consideration of pro and con. > Actually, no: If we decide to update the layout, then it has to be done > now. Otherwise, it does not get included in 2.2.x. IMO it is already too late for a file format change in 2.2.0. So, if we decide to update the layout, we can backport this to 2.2.1 If we decide for a new layout, we can add this in 2.2.1. Günter
