[OPEN-ILS-DEV] After 2.2 naming / schedule

[Jason Stephenson]

Quoting "Lazar, Alexey Vladimirovich" <alexey.lazar at mnsu.edu>:

> 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