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

[Thomas Berezansky]

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" <alexey.lazar at mnsu.edu>:

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