On 12/09/2012 08:21 PM, Uwe Stöhr wrote:
Am 07.12.2012 17:00, schrieb Richard Heck:
After all of this discussion,
Sorry, but why do you decide before I could comment? Please read my
comments from today.
I judged that further discussion was not going to change people's minds,
as indeed it did not.
it seems to me that the consensus is that we should not make major
changes to layout files for minor releases.
Is it a consensus if one developer is not fine with that?
Consensus doesn't necessarily mean unanimous consensus. We almost never
have that, and at some point we have to decide what to do.
What about the users? Have you ever thought about them and/or asked
them? (Se my first mail from today.)
Yes, of course. We are all thinking about the users. We *are* users,
after all. And my intention is that this solution should work reasonably
well for everyone. There's no perfect solution, because you are
absolutely right that there is a real problem here. I've offered a way
to proceed that allows these layouts to be upgraded, as they need to be.
The only issue we are discussing right now is what the new layouts will
be called. And it is fine with me if the template and example files are
changed so they use the new layout, not the old one (though we should
put something into those files that makes it clear that there are
version issues).
In branch, we are conservative. We do the least intrusive thing we can
do. In this case, that means providing new layouts with new names, so as
not to inconvenience people still using older versions. Yes, that will
inconvenience people using newer versions, but, as I said, there's no
ideal solution, and the less intrusive thing to do is not to break
people's documents who haven't upgraded their LaTeX but only their LyX
or who might have difficulty doing so for some reason.
Long-term, as I have said, we need a better solution than we can
possibly have in branch: We need layouts to be version-aware somehow.
Then this issue goes away entirely.
So, if it's something you could do, I'd suggest you put your efforts
there: Add some kind of version detection logic to the configuration
routines, so that the installed version of classes and packages is used
to decide whether a layout file is "available". (My own LaTeX skills are
not up to that, I'm afraid.) I'll be happy to work with you on this.
Maybe JMarc can give us some advice, too. Then we never have this
problem again.
If you want to kick me out of the development please tell me but this
is not fair!
No one wants you to stop being part of LyX. You do lots of important
work, and everyone recognizes this fact. Honestly, I'm a little puzzled
why you are so bothered about this.
I understand Uwe's reasons for wanting to do so, but it will break a
lot of documents for people whose machines do not automatically
update when new class files are released.
Damn! The modernCV layout of LyX 2.0.5 _already_ fails with the
modernCV versions of TeXLive 2009 - 2012. It also fails for all users
using MiKTeX.
This is a separate issue. And for all I know, this really is a bug, so
in this specific case what we should do is upgrade the modernCV layout
to some specific version and provide the old layout in support of older
versions.
So what does my change break?
Here's my problem: If we do things as you propose, then we have
different layout files with the same name under 2.0.5 and 2.0.6. So
people using two different minor versions on two different machines will
find that a single document won't even load properly on the older
version. And that passing it back and forth between the two causes all
kinds of problems. Specifically, files created with the new ACM and
europecv layouts will not load properly in 2.0.5. Then we will get all
kinds of questions like, "I edited my CV on my friend's computer and now
when I get home it won't load on mine!"
My proposal is to ship the new layout, but with a new, versioned name.
If we do that, then files using the new layouts will not load properly
in older versions, either, but in that case you get the "layout not
found" warning, and the problem can be solved *completely* by installing
the new layout file. This isn't perfect by any means, but it seems to me
(and to others) to be much preferable, since the idea of using of a new
layout file that might not have been available on one machine is part of
the LyX ethos already. I.e., it's something you have to get used to anyway.
For the document class files: I state it the last time: You have to
fulfill the submission guidelines. The journals don't care of your OS
and versions. If you don't fulfill the guidelines, you won't be
accepted, point!
Yes, but you are assuming something that does not seem evident, namely:
that everyone who is using these class files is doing so because they
are planning to submit their paper to a journal that uses that class
file. That is not true. People have old files that got rejected, but
they keep them in that format anyway. Those files should not stop
working because they upgraded LyX. People use a certain class file for
pre-prints because they like how it looks without any intention to
submit to a journal in that form. And so forth. For people who do need
to use the new format, they can use it, because we will provide a new
layout file for them that is tailored to the new class file. They just
need to select that one. And we can make it clear in the description
that the old one is obsolete, and use the new one in the template file.
I.e., in the existing acmsiggraph.layout:
\DeclareLaTeXClass[acmsiggraph,lineno.sty]{ACM SIGGRAPH (Old version)}
If we provide layouts for journals, we still will be forced to update
them if a new submission guideline came out, no matter if this means
the addition of a layout style and the change of the number of
argument of a LaTeX command. If my changes for the ACM journals cannot
go in to LyX 2.0.6, I will stop to support any existing journal layout
and also not write new ones because it then makes no sense that LyX
provides any journal layout.
Your changes *can* go into 2.0.6, as new layouts.
Richard
