[sakai2-tcc] Versioning question

[Matthew Jones]

One final comment Re: 10 Years

6/2004 1st Sakai Conference, Denver, Colorado, USA (Even though Sakai 1.0
wasn't released until 2005)
6/2014 2nd Apereo Conference, Miami, FL, USA


On Tue, Jun 18, 2013 at 11:41 AM, Matthew Jones <matthew at longsight.com>wrote:

> Linux further in his write-up makes a stronger point on why we should move
> to a new major. Mostly because KDE and Gnome did because they had breaking
> changes and scary new features.
>
> Linux kernel changed their version even though there wasn't anything big.
>
> This is coming up on the 10 year anniversary of Sakai. So I'd be just as
> happy calling it Sakai 10 (staying in line with 2.10 just breaking out the
> 10) as Sakai 4. I feel like that would be our biggest point of
> disagreement, what major to bump up to. ;)
>
> So what are the big changes?
>
> NOTHING. Absolutely nothing. Sure, we have the usual two thirds driver
> changes, and a lot of random fixes, but the point is that 3.0 is
>
> *just* about renumbering, we are very much *not* doing a KDE-4 or a
> Gnome-3 here. No breakage, no special scary new features, nothing at
> all like that. We've been doing time-based releases for many years
> now, this is in no way about features. If you want an excuse for the
>
>
> renumbering, you really should look at the time-based one ("20 years")
> instead. [1]
>
> [1] https://lkml.org/lkml/2011/5/29/204
>
>
>
> On Tue, Jun 18, 2013 at 11:24 AM, Matthew Jones <matthew at longsight.com>wrote:
>
>> I agree with these 3 points:
>> On Tue, Jun 18, 2013 at 9:34 AM, Berg, Alan <A.M.Berg at uva.nl> wrote:
>>
>>>  Hi all,
>>>
>>> Chuck and Anthony were right of course, we should separate the
>>> conversation out. Here is the recap over the version question in a separate
>>> thread.
>>>
>>> The pluses for a major number change so far:
>>>
>>> 1) David Howitz, builds need to change so major number change is an
>>> honest indicator
>>>
>>
>> It's not just the spring or hibernate, but also all of the new Keitai
>> entities that will be introduced. I think it's also time we break the EB
>> api for 4.0 and require all providers implement a version number which
>> would be in-line with this new version.
>> https://jira.sakaiproject.org/browse/SAK-21959. Adding or changing the
>> providers after this would cause large compatibility issues for external
>> integration, but if they had a way to check the version the external code
>> could work around it.
>>
>> This next version will also have a completely new (inspired by old) build
>> process, which would break any local deployers. So it is quite a major
>> change.
>>
>> 2)  Commercials prefer visioning in line with other products in the
>>> market.
>>>
>>
>> This is also true. Even the linux kernel that was stuck in 2.x seemingly
>> forever (2.6.34) finally made a break and is up to 3.10 from a year or so
>> ago. Even though to the end-user not a ton has changed.
>> When Linux got bumped up, Linus had said, *"I decided to just bite the
>> bullet, and call the next version 3.0. It will get released close enough
>> to the 20-year mark, which is excuse enough for me, although honestly,
>> the real reason is just that I can **no longe rcomfortably count as high
>> as 40*" [1]., More of a recognition release than any technical reason,
>> which is in someways the same for Sakai, but in other cases not because of
>> #1.
>>
>> It seems all major products are just bumping the version. If it's called
>> java 7 by everyone, why still internally use 1.7?
>>
>> I'd be more comfortable calling it Sakai 10.0 over Sakai 2.10. ;) (Was
>> this why you had the Sakai X in all your slides Chuck?)
>>
>>
>>> 3) AMB: Confident messaging, with some nice features and usages emerging.
>>>
>>
>> Ideally some of the new tools we talked about at the conference (signup,
>> dashboard) will be in and others will be on toward deprecation. I feel that
>> the break to 4.0 probably should have happened in 2.9 but this next release
>> with all of the issues makes it sounds like just as good a good time to me.
>>
>> [1] https://lkml.org/lkml/2011/5/29/204
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai2-tcc/attachments/20130618/0dabb0b7/attachment.html