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

[Lazar, Alexey Vladimirovich]

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" <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