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

[Jason Stephenson]

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

> 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