(Sorry that my digest reading means I don't use the In-Reply-To field &
stuff)
From: Andre Poenitz <[EMAIL PROTECTED]>
> It's just another encoding of version numbers. With the "new" scheme
I think you're thinking too much like a Mathematician.
> old: "new"
> 1.1.5cvs 1.3.x "development, many new features"
But we don't have any releases that would fall under this category.
> 1.1.5pre1 1.3.91 "development, bugfixing, some features"
> 1.1.5pre2 1.3.92 "development, bugfixing, sneaking feature
> 1.1.5pre3 1.3.93 "development, bugfixing"
...and since Lars doesn't like 9x, we don't have any of these either.
So why would we want to have a 1.3 cycle?
> It does not affect "development cycle length" at all.
To clarify, there is no such thing as a "development, many new features"
release. That's what Lars et. al were saying about long development cycles.
After the lyx-devel branch languished for months and months, the developers
decided that the separation between devel and non-devel branches had to
stop. (Although they took that back a bit in order to do fix releases.)
Instead, each time a major feature or two goes into the code, its main coder
and/or his (her?) helpers are forced to stabilize it. Otherwise, a coder
might put in some new unstable code and then get distracted by something for
a few months. The great part of this is that it means we
The Linux kernel has pretty long development cycles. I don't know whether
that was because kernels are inherently more complicated and need to be much
more stable than LyX before you can risk an official release, or what, but
Linus was unsuccessful in his attempt to shorten the development cycle.
(Well, maybe he shortened it some, but not as much as he wanted.)
Given the much smaller devel community, we just can't afford to have such
long devel cycles. Therefore, we would never have any 1.3.x releases.
And I don't think it's worth skipping 1.3 entirely just to make a few
people happy.
> It is just a "new" number scheme that happens to be fairly well known
> since a lot of linux related software use it.
And a lot of linux related software doesn't. Since emacs was mentioned, I'll
reflexively throw vim onto the pile. Other examples: all the other GNU tools
(AFAIK), Perl, Python... And do they use the linux kernel numbering scheme in
the world of IRIX, OS/2, HP, and Cygwin?
You had an OK point, but I think it was intelligently addressed, and the
decision was made that clinging to the linux kernel devel numbers for a
project that's very unlike the linux kernel just doesn't make sense --
especially if it would force the us to skip entire version numbers.
> People will not ask themselves whether "pre" is "preferable", "pretty",
> "predictable" or just a "prefix" that happends to stand at the end of the
> word... Urm...
I'm sorry. It's up to us to have an updated website & readme, yes, but the
user has to take SOME responsibility.
> Any distributor checking for new releases sees 1.2.x and says "Oh, that
> number looks stable", perhaps double checks README and voila -
> good old 1.1.4 got on thousands of CDs.
I assume you mean 1.0.4.
So you don't think Perl 5.005, Python 1.5.1... are on any CDs? Yes, LyX is a
smaller project, so they'll pay less attention, but I have to imagine
they'll do a bit better than that. In fact, what they most probably do is
look for a foo.stable.tgz, which we have, linked to 1.1.5.
-Amir
