[WG: Sakai QA] [Building Sakai] Proposal: Sakai 10 and future versioning practices

[Sam Ottenhoff]

I really like the clarity of Sakai 10.  I also like that this provides us a
clean opportunity to re-version our tools, further consolidate our JIRA
projects, and increase our release velocity.

Thanks for putting this forward.  I am looking forward to 10.0, 10.1, 10.2,
and beyond,
Sam


On Mon, Nov 4, 2013 at 2:53 PM, Warwick Chapman <warwickchapman at gmail.com>wrote:

> Excellent.
>
> Release Sakai 10.0, 10 years after version 1 release.  Love it.
>
> The clarity to retain and unclutter the Sakai name cements the now clear
> blue water between Sakai and Apereo OAE (which may perhaps become known
> simply as "Apereo"?).
>
> In order to mitigate potential confusion in the community, you could adopt
> Java's approach and refer externally to the next version as 10 but for
> developers refer to it as 2.10 until the next major release whereafter it
> can be referred to as 11.
>
> -- Warwick Bruce Chapman | +27 83 7797 094 | http://warwickchapman.com
>
>
> On Mon, Nov 4, 2013 at 8:17 PM, Anthony Whyte <arwhyte at umich.edu> wrote:
>
>> *Proposal*
>> End the Sakai 2.x series at 2.9; re-version sakai trunk as 10.0-SNAPSHOT;
>> the next major trunk-based release planned for 2014 will be Sakai 10.0.
>> Thereafter, the following version format will be adopted for community
>> releases and pre-release QA tags:
>>
>> majorVersion.minorVersion[-tagType]
>>
>> Maintenance releases will increment the minorVersion only (e.g., 10.1,
>> 10.2, 10.3).  Whenever trunk is branched in preparation for the next x.0
>> release, trunk itself will increment to the next majorVersion (e.g.,
>> 11.0, 12.0).  Pre-release tags will be versioned
>> majorVersion.minorVersion-tagType in order to designate the level of
>> their maturity (e.g., beta=10.0-b01, release candidate=10.0-rc01).
>>
>> Implementing the new version format and re-versioning trunk will commence
>> on Monday, 11 November 2013.
>>
>> *Rationale*
>> Trunk-based Sakai releases are never minor affairs, involving as they do
>> the inclusion of new or improved capabilities and, occasionally, API
>> changes.  Yet we version our distributions using a minor version designator
>> (e.g., Sakai 2.7, 2.8, 2.9).  Likewise, Sakai maintenance releases offer
>> scope for the inclusion of minor enhancements yet are versioned with an
>> incremental x.y.z designator (e.g., Sakai 2.9.2, 2.9.3) as if they
>> represent nothing more than a rollup of bug fixes.  As we look to the next
>> major Sakai release, the opportunity now exists to both break out of the
>> 2.x series and revise our approach to versioning in order to better reflect
>> the Sakai's development/release practices.
>>
>> Earlier in the year it was suggested that we version the next release
>> Sakai 10, an imaginative yet shrewd suggestion that allows us to celebrate
>> in two digits both the inaugural release of Sakai 1.0 in 2004 as well as
>> the staying power of the community.  Since then, the Sakai 10 idea has
>> gained a good deal of traction on the community lists.  Embracing 10 also
>> helps us steer well clear of "Sakai 3", a legacy version considered
>> historically problematic by many in the Sakai Community.  We also avoid
>> having to rename Message Center artifacts--the latest of which are
>> versioned 3.0.3 for 2.9.x--in order to avoid version collisions.[1]
>>
>> Note too that the proposal dispenses with the acronym "CLE" when
>> referring to the next release.  Now that OAE has re-branded itself under
>> the Apereo banner no compelling need exists to qualify or otherwise
>> overload the Sakai name with a trailing three-letter moniker.  Sakai 10:
>> clean and simple.
>>
>> *Implications*
>> The possibility exists that the change will induce a certain level of
>> confusion in a community used to the 2.x.y series format.  We will need
>> consistent messaging going forward.  In addition, a certain amount of ink
>> has been spilled in emails, Confluence and elsewhere referencing 2.10
>> (though usually with disclaimers attached).  Documents focused on the next
>> major release will need to be updated.
>>
>> *Limitations*
>> 2.x maintenance releases and pre-release tags (if any) are outside the
>> scope of this proposal and will continue to use the current
>> majorVersion.minorVersion.incrementalVersion[-tagType] versioning format.
>>
>> A material objection raised by a Sakai PMC member will block this
>> proposal.  Other opinions are welcome, indeed encouraged.  Silence equals
>> consent.
>>
>> Cheers,
>>
>> Anthony
>>
>>
>> anthony whyte | its and mlibrary | university of michigan |
>> arwhyte at umich.edu | 517-980-0228
>>
>>
>>
>> _______________________________________________
>> sakai-dev mailing list
>> sakai-dev at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>
>> TO UNSUBSCRIBE: send email to
>> sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of
>> "unsubscribe"
>>
>
>
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to
> sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of
> "unsubscribe"
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-qa/attachments/20131104/115c844a/attachment.html