Oct
21
Written by:
Anthony Whyte
Tue, 21 Oct 2008 11:38:20 GMT
I've generated the first Sakai 2.6.0 tag for QA: sakai-2.6.0-alpha01. It is available at
https://source.sakaiproject.org/svn/sakai/tags/sakai-2.6.0-alpha01
I originally planned on creating a 2.6.0 branch (in line with what I do for maintenance releases) and then cutting the alpha01 tag from it once I had tweeked the POM values to more closely match the tag name but my colleagues prevailed on me to hold off on branch creation and cut the tag directly from 2-6-x in order to keep branch management (i.e., merges) at a minimum.
The advantage of working from a 2.6.0 branch rather than from the *x branch is the greater control one can exert on what ultimately ends up in the release. Recall that 2-6-x .externals contains no revision numbers; tags created directly from 2-6-x will either represent the head of 2-6-x or some single revision number (e.g. take 2.6.x -r 53634). A separate 2.6.0 branch allows one to massage the .externals with respect to revision numbers (indeed even projects) independently of the *x branch, aligning project revision numbers with actual project commits and if necessary, narrowing the scope of a release if required.
But the greater control one can exert comes at a cost in terms of branch management: particularly early on during the alpha phase when the many fixes destined for 2-6-x and ultimately the 2.6.0 release would require merging to two branches rather than one. Hence the concerns raised by my colleagues.
However, once the alpha phase of testing is complete, I recommend that when tagging the first release candidate (if not earlier), we do so not from 2-6-x but from a newly minted 2.6.0 branch. By then the code should be stable, the number of required fixes should be on the decline along with the merge management overhead. Greater control can be exerted over the range of fixes going into 2.6.0 and 2-6-x maintenance work need not be slowed by 2.6.0 release issues. It should also permit us to better apportion our QA resources. Additionally, 2-6-x dependency management need not be limited by 2.6.0. I'm thinking here of the Kernel. Currently 2.6.0 and 2-6-x both bind to the Kernel 1.0 release. This makes sense from a stability standpoint for 2.6.0 but 2-6-x could take advantage of the fixes going into the Kernel-1.0.x branch and bind itself to 1.0.1-SNAPSHOT and subsequent updates.
All compellng reasons from my standpoint to create a 2.6.0 branch as soon as is practical.
Copyright ©2008 Anthony Whyte
Tags: