On 2016-04-05, Richard Heck wrote: > On 04/05/2016 04:36 AM, Guenter Milde wrote:
>>>> For the other patch (acmsiggraph.layout with incompatible version >>>> but same cls file name), I would wait for an agreement whether to >>>> update the layout (file format change needed) or add a new one. My >>>> last preference is an updated layout file. >>> Does anyone disagree with having a new one? This point (do we allow a new layout version when there is no change in the *.cls file name) was still not settled. Even if I originally came up with the idea, ... >> I actually prefer an update over a new one: >> UPDATE: >> +1 keep *.cls file name and *.layout file name in sync. > Doesn't seem particularly relevant to me. >> +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. >> +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.) >> +1 obsolete styles can be sorted in a new group "Obsolete" and be >> given a label indicating the status (see below). > This could be done anyway Yes. > and has nothing to do with and it allows for keeping the styles in a current layout file (at least until the last upstream version supporting them is no longer widespread "in the wild"). >> -1 file format update required due to new styles > This means that we have to do different things in master and stable. >> NEW "versioned" layout: >> -1 different names for template/upstream documentclass and layout > As I said, I don't see that this is relevant. The layout file naming > scheme is not visible to the user. >> -1 two layouts for a rarely used document class > Only one of which has to be maintained. >> +1 no file format update required > This is a big one, more like +100 in my book. I see that this is a big saving. However, building up cruft because this makes things easier is -100 for me. Two more reasons for updating the layout: +1 This is the established method to keep upstream class file and layout in sync. We should have generic methods how to handle this in lyx2lyx. +1 Automatic conversion of documents to the new layout > Please note that, in this one very special case, where the release of > 2.2.0 is around the corner, we have this choice. We will not usually > have it. Generally, we have the choice: Updating: * update layout (adding/removing styles) in trunk -> file format change (ffc) * update template/example in trunk and stable branch * provide updated layout via wiki (or repo) for local installation in stable - no updated layout in stable Version-layout: * new layout in trunk and branch For the specific case of acmsiggraph we have the special side constraints: * feature freeze * 2 concurrent patches for new layout ready * last chance for updated layout in 2.2.x, if we rush the decision. * very specific (exotic) document class If the choice is for updated layout + ffc, we must hurry (but I cannot help with lyx2lyx). If the choice is for new versioned layout, there is no need to force the patch in now. This means, unless someone voluntees to do a ffc, there is time for careful consideration of pro and con. Günter
