Quoting "Lazar, Alexey Vladimirovich" <[email protected]>:
Any particular reasons for the March/September release schedule
versus any other months?
There was some discussion of this on IRC back in December/January.
The March/September dates were chosen by the participants in the IRC
discussion because they seemed like they would work the best for all
of the various types of Evergreen sites: public, academic, mixed
consortia, etc.
You could try searching the IRC logs to find the discussion:
http://www.open-ils.org/irc_logs/evergreen/
As far as versions, are there known pros and cons for either scheme?
Is anything wrong with the current scheme?
As I pointed out, all version schemes are more or less arbitrary. I'd
be happy if we abandoned numbered releases and everyone would just run
master from git, using either the time/datestamp or the commit hash of
their checkout for their version number.
The problem with the current scheme is that it isn't being used. If
you go strictly by the versioning document that was linked to in
Bill's original email and compare that with the changes made in
Evergreen and its prerequisites since 1.6, you'll soon figure out that
what we're calling 2.2, should actually be called 4.0.
* 2.0 was right to be called 2.0.
* 2.1, however, bumped the version requirement of postgresql, so
should have been called 3.0.
* 2.2 again bumps the required postgresql version, and so should be
called 4.0.
If the new xulrunner branch goes in, then what might be called 2.3
should be 5.0, if you're following the above train of logic, or 2.3 or
3.0 if you're not.
If we're going with timed releases, then it makes sense to just name
the releases for the date of release. This doesn't bind us to any
particular scheme of incrementing versions when certain features or
requirements are modified.
All of that being said, I'm not terribly invested in version numbers.
I've been around long enough to see Slackware jump from version 4.x to
7.0, because RedHat was at 5.2 and people kept asking when Slackware
"was going to upgrade to Linux 5?" Never mind that the kernel was 2.0
or 2.2 at the time. I've seen the Linux kernel major version frozen at
2.6 for how many years, only to recently see it changed to 3.0 and
now, 3.2.
Further, as some one who runs Evergreen from the master branch on git,
and does updates at semi-arbitrary points dictated by the availability
of new features and the desires of my consortium's members, version
numbers mean even less to me, personally. Our clients are currently
stamped 2.2.0.mvlc.3, but they could just as easily be 20120411.
I'd also like to site the mplayer and mplayer2 projects. They have
recently dropped version numbers all together. In fact, if you install
from recent tarballs, the configure or make echoes text to the effect
that: "The mplayer developers no longer believe in versioned releases.
Please get the latest code from our git repository, etc."--I find
myself in that camp lately, particularly as regards Evergreen.
I am not opposed to version numbering schemes when they make sense and
they are applied consistently. This has not been the case for
Evergreen's scheme so far, so I see no reason to continue with it.
I'd *prefer* a system based on the dates of the releases if we go to
date based releases. I am not *married* to it, and will continue using
Evergreen the way I currently do regardless of the community's
decision. If the decision is to stick with the willy-nilly numbering
scheme as currently used, then that's OK with me.--I won't stage a
coup to have things changed.
:)
Alexey Lazar
PALS
Information System Developer and Integrator
507-389-2907
http://www.mnpals.org/
--
Jason Stephenson
Assistant Director for Technology Services
Merrimack Valley Library Consortium
Chief Bug Wrangler, Evergreen ILS
