On 01/01/2013 10:34 PM, Uwe Stöhr wrote:
Am 16.12.2012 19:33, schrieb Richard Heck:
1. backward compatibility
Perhaps I am reading too much into this, but if your main concern is
the example or template file,
then there is no issue here. I have already said that I have no
objection to making the example and
template files be up to date, in the sense that they use the updated
layout. It's just that this
layout will have a new name. So this is not an issue.
I am referring to the fact that we need to keep the layout files up to
date corresponding do their .cls file. It is in my opinion not
acceptable that adding a new style to a layout file should not be
allowed for branch. And that is the most important point for me and
the reason why I fight!
I'm sorry, Uwe, but you simply are not listening to what anyone else is
saying. No one is saying we should not provide updated layout files,
force people to enter TeX code, or whatever. The ONLY issue is what the
names of these new layouts will be. I'll address your concerns about
this issue below. But it is the only one worth discussing. Explaining
why we need to be able to offer updated layout files, so people can
submit to journals, etc, is not helpful. We agree about this. It just
annoys people that you can't acknowledge that agreement and keep trying
to rehash it.
2. scientific document classes
If this is about the template, then again there is no issue here: It
can use the updated layout. And this will make it easier for
inexperienced users to choose the right layout, since they will very
often start with the template.
No, it is about the fact that we must provide an up to date layout
file for scientific classes that allow to fulfill the submission
guidelines.
It says, right there is what I wrote: It can use the *updated* layout.
So, again, there is no issue about this.
As for the rest: Plenty of people use year old versions of Firefox, or
whatever. Python 2 co-exists with Python 3. The TeXLive version that
ships with most Linux distros does not have a package manager. And so
on, and so forth.
4. the proposal with layouts for different document class versions
Let me address the last point first. I do not see why you think
versioning makes more work. Why would you have to write three
different layouts? To support every single version of moderncv?
Yes.
We don't do that now, as you said.
You misunderstood me then. We always did so in the past and I want to
keep this because it has been proven to be useful. Our layouts must be
up to date to be useful - to fulfill submission guidelines for
scientific classes and to be able to compile it with the latest .cls
file version on CTAN, see my argumentation above.
Well, in that case, it isn't any more work. If we're doing it anyway,
why does it matter what the new file is called? The old one gets
deprecated, but it stays in the tree, throughout a given major release.
Why would we have to do it then? Are you worried that, if a layout is
tied to a version thus:
version=0.15
then somehow it stops working when the version changes?
No. I am against to force users to learn about their package version.
Getting this is even with TeXLive not that easy. So having many
layouts for one single class is confusing and complicated too for
average users.
Before I continue, I should state how I work on LyX: I imagine I would
sell it. What can I do that more people buy my product? Answering that
leads automatically to a user-friendly program. I develop LyX that as
many people as possible use it and not as a tool for experts being who
know what a LaTeX-package is.
As an average user I expect that I have to choose a document class and
my document will compile - nothing more!
Well, then you will be frustrated, on either proposal, won't you? On
your proposal, your new layout will not compile with older versions of
the class, which lots of people will have. At least on mine, there will
be a layout that you can use. And please do not tell me again about
package managers, and how no one uses old versions of the class. We have
been over that.
In any event, this is now not a discussion about whether we can or will
allow the shipping of a certain version of a layout. It is about what is
best for users, among choices all of which have their downsides. A large
majority of developers prefers one of the two solutions.
Option (1) thus breaks compatibility across minor versions of 2.0.x,
and that is just
not acceptable, in my opinion and that of most of the other
developers. That is why I thought I could make a decision when I did:
Because once it has been decided that we cannot break compatibility
across minor versions---
I don't understand your argumentation. We always allowed to break
compatibility across minor versions: Every changed layout in branch
did this also every new Windows installer feature.
The Windows installer is your business.
2 examples:
-
http://www.lyx.org/trac/changeset/0d174e9e0d0ed032a7063c4f1d427affefd60170/lyxgit
(change made by the that time branch manager)
This is a fairly minor change, and easy to work around. Just don't use
that one new layout, if it is a problem. Yes, there are gray lines here,
and judgement calls. But this clearly goes on one side of that line.
- elsarticle.layout: we got many user complaints about that Elsevier
created a new document class one had to use for any submission but we
only supported the old and obsolete elsart class. So I had to write a
layout which had to be introduced in a bugfix release. If would have
been forced to wait until LyX 2.0 we would have for sure lost users.
No one is suggesting we wait until 2.1.
- support for multiple indexes. I added support for this with a LyX
for Windows installer (requires some trickery with Perl). So if you
use e.g. LyX 2.0.3 on Windows you cannot use this feature, it only
works with LyX 2.0.4.
The Windows installer is your business.
Richard
