Gets ported to Debian? It already runs on Debian.
As for the numbering, using the last digit results in...
2019 - 9.x
2020 - 0.x
I think there is a problem there. Using 2 digits we don't have a
problem like that until the 2099-2100 jump.
Thomas Berezansky
Merrimack Valley Library Consortium
Quoting "Lazar, Alexey Vladimirovich" <[email protected]>:
I'm +1 with a date-based scheme, but I would like the transition to
be smooth and seamless, not a big jolt, even if only perceived.
For this reason, if we do switch to a date-based numbering, may I
suggest that rather than using YY.MM like Ubuntu, we would just use
the last number of the year for the first digit of the version,
followed by .0 or .1 depending on if it's the fist or second major
release of that year. Minor bug fix releases would be the third
digit then. That all starting with the March release of 2013.
So, the transition would look something like the following.
Rolling on current numbering:
2.2 - current release
2.3 - September 2012 release
Now, smoothly and seamlessly transitioning to a date-based scheme,
while the numbering continues to increase monotonically:
3.0 - March release of 2013. Minor releases, if any: 3.0.1, 3.0.2, etc.
3.1 - September release of 2013. Minor releases, if any: 3.1.1, 3.1.2, etc.
4.0 - March release of 2014. Minor releases, if any: 4.0.1, 4.0.2, etc.
4.1 - September release of 2014. Minor releases, if any: 4.1.1, 4.1.2, etc.
And so on. This way we can abandon the current scheme that fell out
of use, and adopt a new simpler scheme naturally without a big to-do
about it. Let's reserve a HUGE version jump for when there is a
SIGNIFICANT change in Evergreen, e.g., it gets ported to Debian, or
something of that magnitude.
Alexey Lazar
PALS
Information System Developer and Integrator
507-389-2907
http://www.mnpals.org/
On May 17, 2012, at 10:53 , Jason Stephenson wrote:
Quoting "Lazar, Alexey Vladimirovich" <[email protected]>:
Using this scheme, does that mean abandoning minor release
numbers? If yes, I'm against that. If no, what would minor
releases look like, 12.09.1 or 12.09.0.1? Ubuntu does not seem to
be using the minor release numbers.
Ubuntu does use minor release numbers. The current "version" of
Ubuntu Lucid Lynx is 10.04.4. Thing about the Ubuntu updates is
that you typically get them in a rolling fashion, so you might not
notice when minor versions are added.
The core of my argument is this:
Are we focusing on feature releases or timed releases? If the
former, then version numbers tied to features/bug fixes makes
sense: 2.2.0, 2.2.1, 2.3, 3.0, etc. If the latter, i.e. we're just
releasing what's deemed ready on a certain date, then they make
less sense, since there is no guarantee of what features are in a
given release or what the relationship of features to release is
any longer.
What it sounds like the majority wants is to have a timed release
schedule, but to focus on feature-related versioning schemes. I
have no real objection to that, but don't surprised when releases
slip because planned features are not ready.
As I stated earlier in this thread, my main objection to the
feature and dependency-related version scheme is that we aren't
using the current one as it is described. I has, de facto, become
meaningless.
As Rogan has pointed out, the version numbers have a psychological
effect on the community:
"As for the numbering ... aside from the rational and reasonable
reasons for 2.3 versus 3.0, there is the psychological as well.
Let's just say a jump to 3.0 will generate some ... anxiety."
I think that's another argument for switching to date-base versions
or even named releases, dropping version numbering schemes all
together.
In these days of DVCS where the hurdle of installing from git is
hardly any higher than installing from a tarball, version number
schemes make less sense than in the past. I have already pointed
one project that has abandoned versioned releases in favor of
telling people to use git. I think version numbers should be a
thing of the past. As a programmer, I've often preferred to install
the packages that I care the most about from source and to make
sure that I have the absolutely latest code when I encounter an
issue.
From a free software community perspective, I don't see how support
gets any harder under this model. You end up asking all of the same
questions. And, you have a very good answer to any unknown problem:
update to the latest master and see if the problem persists, if so,
we'll open a bug. How is that any different than saying, "Oh,
you're on 2.0.5 and the latest is 2.0.11. Update to 2.0.11 and tell
us if the problem is still there."?
Dan Scott and, I think, Mike Rylander referred to it as Point In
Time Support, or PITS. What's a versioned released is not a Point
In Time Release? And what is support for that release if not Point
In Time Support? Doing it with commit hashes is no different. (That
was from IRC for those not following along at home.)
The hurdles to installing Evergreen are already fairly high, and if
one can install it from a tarball, one can just as easily install
it from git. (Instead of wget some-url or downloading in a browser
and using scp, you just type git clone some-url.)
All of that said, I don't really care what versioning scheme is
used. I'd only suggest that it be rational and consistent (and
applied consistently as the current one has not).
If the focus of development is on regular, date-bound releases,
then I'd prefer date-related versions, even ISO date stamps,
Ubuntu's scheme is only an example. Even just ratcheting the major
version every six months in imitation of Mozilla works in that
regard.
If the focus is on getting certain features into certain releases,
then version schemes like the current one make more sense.
Me, I'm happy just using commit hashes and/or the timestamp when I
ran the make install command.
For someone who claims not to care about the versioning, I sure
have spent a lot of time typing about it.
--
Jason Stephenson
Assistant Director for Technology Services
Merrimack Valley Library Consortium
Chief Bug Wrangler, Evergreen ILS
