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!
Our layouts are offers to the users. LyX is only as useful as its layout files are. So if you want
to use a new feature of your preferred class, your should not be forced to learn tricky TeX-code,
play with ERT or preamble code. LyX should offer this!!! And waiting 2 years for the next major LyX
release is in modern times no option.
(I'm still wondering about your (LyX developers) experiences. In my our potential user group
(students scientific researchers) wants a system that works out of the box will as much as possible
features. If you tell them they have to enter TeX-code they will immediately go back to Word. Trust
me - I already introduced LyX to so many people and gave courses. The Windows installer was one
consequence of it: just click a few times OK and next and you get a fully functional system. The
other consequences was to write layout file and to offer a thesis template.)
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. Otherwise the layouts for that document class types are
quite useless. Imagine how frustrating it is to write a paper but when submitting it, the automated
submission systems will deny your file not telling you why exactly. Personally I had this case
twice. It cost me about a day to find out that images were too wide and the image caption was not
above the image but below (or something similar, can't remember it exactly). I can imagine that an
average user would the next time not use LyX but directly LaTeX or Word. So if Lyx should be
attractive to use it for sientific reasearchers, we must assure that the submission guidelines are
fulfilled or we drop support for these document classes to be consequent.
3. "my LaTeX system is too old"
Obviously, there are extreme cases we cannot support.
But where do you draw the line what to support and what not? LyX is an offer to the users and as
such as user I can expect to get a fully featured program.
I already explained why for me discussion about this topic is very, very strange. Let's face the
reality: every program you can purchase or download offers bugfixes and new features from time to
time. The time period between releases is usually some months for good reasons because all the time
bugs occur and have to be fixed. No matter if you have to pay for support or not, only the latest
version is supported (except of some fundamental programs like an OS). LyX does the same and when we
get a bug report that LyX 2.0.2 contains a bug, we since ever replied "use LyX 2.0.5" where the bug
is fixed. The same is with all LaTeX-packages, and third-party programs we use.
To be drastic: Would you use a one-year old Firefox or Java or Flash or Python? Of course not
because the old versions have known vulnerabilities.
That Software needs to be updated from time to time is a matter of course.
But we need to be sensitive to a range of
different platforms and what TeX installations are currently being used on
them. We should not just
assume that everyone is using the latest and greatest version of every package
and class, because we
know they are not.
The user is free to use a version he likes, but if it contains a bug and there is a new one out that
fixes it, it is a matter of course to upgrade to that version.
I will also add that, if our concern is with inexperienced users, then telling them
"Well, you need
to update your europecv package" doesn't strike me as very helpful. This is not
something that even
an average user knows how to do. (And no, not one of my machines uses any kind
of TeX package manager.)
What is so complicated to use a TeX engine with a package manager? I also use TeXLive and there I
got to the package manager search for europeCV, click to update it and that's it. I cannot image why
this is in your opinion too complicated for everybody - this is self-explanatory. What is your TeX
engine?
However, we cannot be responsible for what a user might have installed and what rights he hes to
install. I mean, if you are for example on Windows but in a company and therefore don't have admin
permissions you still can install lyx but some features might not work. But we of course
nevertheless provide that feature.
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.
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! Why should I like to be confronted with e.g. 4 different versions of a document class?
And these version tell me e.g. "version 0.15-0.19". Coll, but what the hell is that about? I might
then google about my preferred class but this doesn't help me to find out which version I need and
what are the differences between them. They arise more questions than they solve.
Besides this all the years we have needed different versions of layouts but now we do? Nobody
complained e.g. that we upgraded the Springer layout files. We never got a complaint, only positive
feedback And in the case of Springer we even break backward-compatibility completely. (Not that I
wanted this. It is only an example that being even that drastic is possible.)
At least with versioning, we would have the option of writing different layouts
for different
versions, rather than ship a moderncv layout that we *know* works only with
some versions.
But the modernCV case is a good example that we don't know. I cannot tell you how a layout must be
that can be used with modernCV 1.0. The old one worked with version 0.x but I cannot even tell you
what x is. I don't have that much time to check for every single file release the layouts and update
them immediately. Before a new bugfix release I check my layouts with the .cls file that is that
time available on CTAN. If there are several class file releases within our bugfix update cycle i
would lost track. For example version 2 was available when LyX 2.0.3 came out and version 5 when LyX
2.0.4 cam out. I cannot tell if the layout worked with version 3 and 4. But a LyX user might have
version 3 installed.
As for the other concern, we need to separate the short-term and long-term
issues. Long-term, we are
all agreed that this problem needs to be addressed properly for 2.1,
That is too long. A researcher who has t submit for a conference cannot wait 2 year for the next
major LyX release. The same is for a student that wants to write his CV to apply for a job. - That
is my point 1 in this thread.
Short-term, we cannot consider this solution, so there are only two options:
1. Ship updated layout files *in place of* the older ones.
That is what we have done since I work with LyX, see the examples at the end of
this mail.
2. Ship updated layout files *alongside* the older ones and update the
example and template files to use the new layout.
Both options have their drawbacks, which is why we need to do something better
for 2.1. But, in my
opinion, option (1) has worse drawbacks, and the drawbacks are worse the more
extensive the changes.
Have we ever got a complaint from users about that? I cannot remember such a
case.
(If the changes are not extensive, and we are just talking about tweaks, then
that's an entirely
different matter. But that's not what we are talking about here. Tweaks are
fine.)
And what is a tweak? Where do you draw the line?
With option (1), on the other hand, a LyX file edited using 2.0.6 will not
behave the same way under
2.0.5: It will not export or compile properly, *even if* the user has an
updated class file, because
the new styles will not be recognized and so will be treated as "Standard". The
user will get some
warning about this---specific layouts not found---but may well be puzzled about
why, when they are
using the "same layout" they were using on their other machine (or that their
collaborator is using,
or whatever).
I'm wondering about your experience. The rule number one for a collaboration is that everybody in
the team uses the same software. I even had projects where this was contracted. Nobody come to the
idea to collaborate if person A has Word 2003 but person B has 2010. This will never work out. Out
current method (1) that we used since ever shows that people are not stupid and can imagine that you
need toe same program version to run a file edited with that. What would you do if your OpenDocument
file written with LibreOffice 3.4 does not compile with LibreOffice 3.3? I would upgrade the other
machine also to LibreOffice 3.4. I guess the vast majority of users would do so. And that is why I
will start a survey on the users list.
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.
2 examples:
-
http://www.lyx.org/trac/changeset/0d174e9e0d0ed032a7063c4f1d427affefd60170/lyxgit
(change made by the that time branch manager)
- 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
- 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.
regards Uwe
