On 03/28/2016 06:50 AM, Georg Baum wrote: > Richard Heck wrote: > > On 03/25/2016 02:34 AM, Scott Kostyshak wrote: > [This is about the case of a NEW class file, i.e., with a new name.] >> I don't myself see why we shouldn't add the new layout file, which is >> this case is completely new, to branch. No conflict can arise in this >> case, other than that one user has the layout file and the other >> doesn't. Sure, both users could download it, but it would be easier for >> one of them to download it. And if one of them has downloaded it and the >> other hasn't, then one of them has it and the other doesn't, and it's >> not very different from what happens if we included it in the distro. >> Note also that putting it in the distro advertises the existence of the >> new layout. > It all boils down to the question: Is the addition of a new .layout file a > file format change or not? It does not make sense to treat new layouts > differently in stable and master, so either it is a file format change in > master (and can't be put directly into the stable version), or it is not, > and then it can simply be added both to master and stable. > > The same question is valid BTW for new modules. Currently we are a bit > inconsistent here: New modules are not treated as file format changes, but > new layouts are. > > IMO, we should make a list of pros and cons for "new layout files are a file > format change", and the same for modules. I guess that a decision will not > be difficult once we have such an explicit list. Below you can find the pros > and cons I am currently aware of: > > > Pro "new layout files are a file format change": > - All documents produced by 2.2.x can always be edited and exported even if > x is different. This is important for people using different machines, or > echanging work wth colleagues. > > Con "new layout files are a file format change": > - No new LaTeX classes can't be supported in a stable version > - We have the same situation already with custom layout files: If a document > using a custom layout file is interchanged, the layout file needs to be > interchanged as well. If that is not done, then we have a fallback > implemented so that such documents can still be edited, but not exported, > and the user gets a warning. > - lyx2lyx cannot do anything useful on backward conversion, and the forward > conversion would be a noop > > > To me it looks like the Cons are more important, so I tend to change my mind > and agree with Richard here. Did I miss anything?
Not so far as I can see. And of course people can always get the new layout file, either from git.lyx.org or from the other installation or whatever. (It's possible that an error message mentioning this would be a good idea.) >>> 3b. The .cls file has been updated but uses the same name. >>> >>> 3bi. Only new styles have been added. >>> - Regarding branch, this is covered in the section of Development.lyx >>> that is currently "2.6 Backporting new styles to the stable version" - >>> Regarding master, we can just update the layout directly without any of >>> the renaming of files that was necessary in (3a). >> Let me just say thanks again to Georg for sorting this out. > To my konwledge, this mechanism has not been used yet at all. I conclude > from this that this whole discussion is much less pressing than it seems at > a first glance. Possibly. It tends to seem very pressing when it arises, then it goes away again. >>> 3bii. It is not just that new styles have been added. I think it is going to be dang-near impossible to reach consensus on this now. And, for the reason just given, I'm not sure we need to do so. If really pressing problems of this kind arise, I'll handle them. on a case-by-case basis. The proper solution is versioning, and that will be in 2.3. > We need to be very careful here: Producing a PDF from a LyX file must not > produce different results depending on the LaTeX installation, this would be > very confusing. Is this avoidable? If people have different versions of a class file, can't that produce different output? Richard
