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

[Anthony Whyte]

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-qa/attachments/20131104/d2d475ce/attachment.html