[sakai2-tcc] Versioning question

[Matthew Jones]

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/8457c290/attachment-0001.html