[Building Sakai] 2.6.x pom <version> after 2.6.0 release

Thu Mar 26 13:33:05 PDT 2009

I really do feel that the maintenance releases should have a stable  
<version> number associated with them, which does not change over time  
as tags are released. So like 2.6-SNAPSHOT or just 2.6.x. But not  
2.6.1-SNAPSHOT as that would later change to 2.6.2-SNAPSHOT, then to  
2.6.3-SNAPSHOT and so on.

Other projects (eg Apache Wicket) use a branch <version> similar to  
this. Tagged releases are like 1.3.3, 1.3.4, 1.3.5, just like us, and  
there is one 1.3.x branch with it's version at 1.3-SNAPSHOT. This  
branch version is stable and as fixes go into the branch, a new  
version is tagged, 1.3.6, but the branch remains at 1.3-SNAPSHOT as  
it's still the same singular 1.3 branch. Trunk is the only moving  
version which would be at 1.4-SNAPSHOT in this example.

If we have a changing branch <version>, it's going to mean a lot more  
manual intervention in removing deployed artifacts from the previous  
'branch' (ie as it changes from 2.6.1-SNAPSHOT to 2.6.2-SNAPSHOT). So  
you couldn't just do an svn update in a branch, build and be on your  
way as the version might have changed. One of the main requirements  
behind the current maintenance branches is that they remain very stable.

There is currently no undeploy goal in our build process like there  
was in 2.4.x which would clean up an old version. Perhaps we need to  
look at this again (http://bugs.sakaiproject.org/jira/browse/SAK-13280).

Also, when did we shift to suggesting people use point releases rather  
than the maintenance branch in production?

regards,
Steve

>
>
> On Thu, Mar 26, 2009 at 6:04 PM, Anthony Whyte <arwhyte at umich.edu>  
> wrote:
>> Opening this conversation up to the dev list for further comments:
>>
>> Steve--well, in a world were we could use the Maven release plugin
>> with the whole of Sakai (which does not exist at present; although I
>> think we can sort out the problem with some project/pom naming
>> realignments) we could perform releases from the 2.6.x branch as we
>> do now from K1.  In such a case the release plugin would generate a
>> 2.6.0 tag and then the plugin would increment the pom <version>
>> number of the 2.6.x branch to 2.6.1-SNAPSHOT and commit the changes
>> automatically.  Then 2.6.0 artifacts are created and placed in the
>> repo.  This is how K1 <versioning> works and I expect Ian intends for
>> K2 to work the same way.   All of this you know so I apologize here
>> for stating the obvious.
>>
>> The point I am trying to make above is that the maintenance branch
>> should be viewed as a SNAPSHOT set of code that by definition is
>> rather more fluid in nature than a point release (using M2 as a fixed
>> version number as you recommend obscures this).  Indeed, it is no
>> longer the case that we (the Foundation) actively advise people to
>> run their production instances off a maintenance branch.  Our goal
>> has been to undercut the old adage that friends don't let friends run
>> Sakai point releases in production by producing reliable maintenance
>> releases that are produced regularly to a well understood timeline
>> (the latter still a goal).  We have had a modicum of success here
>> with the 2.5 maintenance series as I see now that a fair number of
>> schools are running 2.5.2, 2.5.3 and 2.5.4 in production.  I
>> recognize that more experienced production houses tend to run off the
>> maintenance branch but over time I expect this to become the
>> exception rather than the rule given the number of smaller
>> institutions that run (and will run) point releases of Sakai.
>>
>>  From my perspective, I think consistency in our versioning practices
>> is important and I believe the "Maven" practice first adopted by Ian
>> works well.
>>
>> trunk:  [major.minor]-SNAPSHOT
>> release tag: [major.minor.revision]
>> 1.0.x branch [major.minor.revision]-SNAPSHOT
>>
>> This is an area were I believe it would be good to settle on a
>> general practice since there may be advantages to the community of
>> having a few other core projects adopt their own release cycles
>> independent of a general Sakai release.  Our practices are a bit
>> inconsistent at present as a few examples will demonstrate:
>>
>> Examples:
>>
>> Sakai (after 2.6.0 release)
>> trunk:  [major.minor.revision]-SNAPSHOT  (e.g., currently 2.7.0-
>> SNAPSHOT, IMHO should simply be 2.7-SNAPSHOT)
>> tag: [major.minor.revision] (e.g. 2.6.0)
>> 2.6.x branch [major.minor.revision]-SNAPSHOT (e.g., 2.6.1-SNAPSHOT)
>>
>> K1 (after 1.0.4 release)
>> trunk:  [major.minor]-SNAPSHOT  (e.g., 1.1-SNAPSHOT)
>> release tag: [major.minor.revision] (e.g. 1.0.4)
>> 1.0.x branch [major.minor.revision]-SNAPSHOT (e.g., 1.0.5-SNAPSHOT)
>>
>> K2 (current)
>> trunk:  [major.minor]-SNAPSHOT  (e.g., 0.1-SNAPSHOT)
>> release tag: [major.minor.revision] (no tag yet)
>> branch [major.minor.revision]-SNAPSHOT (no branch yet)
>>
>> SiteStates (current)
>> trunk:  [major.minor]-SNAPSHOT  (e.g., 2.0-SNAPSHOT)
>> release tag: [major.minor.revision] (e.g., 1.2.1)
>> branch (no 2.6 branch yet; I assume this would be 1.2.2-SNAPSHOT)
>>
>> EntityBroker (current)
>> trunk:  [major.minor.revision]-SNAPSHOT  (e.g., 1.3.7-SNAPSHOT, IHMO
>> should simply be 1.3-SNAPSHOT)
>> release tag: [major.minor.revision] (e.g., 1.3.6)
>> 2.6.x branch [major.minor.revision]-SNAPSHOT (currently, 1.3.6-
>> SNAPSHOT, IHMO should be 1.3.7-SNAPSHOT)
>>
>>
>> Cheers,
>>
>> Anth
>>
>>
>> On Mar 26, 2009, at 12:20 PM, Steve Swinsburg wrote:
>>
>>> My only worry with this is is that the number will change, rather
>>> than be stable like the 2.5.x series of M2. So then someone doing a
>>> simple SVN update of just one module perhaps will get an updated
>>> POM which doesn't match the rest of their dependencies.
>>>
>>> My feeling is that the branch version number should be more stable
>>> since we advise people to run it in production?
>>>
>>> Hmm,
>>> Steve
>>>
>>>
>>> On 26 Mar 2009, at 16:13, Anthony Whyte wrote:
>>>
>>>> Currently, 2.6.x poms have a version of 2.6.0RC1-SNAPSHOT (it
>>>> really should have just been 2.6.0-SNAPSHOT).  Steve has enquired
>>>> what the <version> for the *x branch will be after the release of
>>>> 2.6.0 (the release to occur from a 2.6.0 branch that I will create
>>>> when we do the first RC tag).
>>>>
>>>> My recommendation is:  2.6.1-SNAPSHOT, the revision number to be
>>>> incremented by +1 whenever we do a maintenance release (e.g. 2.6.2-
>>>> SNAPSHOT, etc.).
>>>>
>>>> Any objections?
>>>>
>>>> Cheers,
>>>>
>>>> Anthony
>>>
>>
>> _______________________________________________
>> 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"
>>
>
>
>
> -- 
> Aaron Zeckoski (aaronz at vt.edu)
> Senior Research Engineer - CARET - Cambridge University
> [http://bugs.sakaiproject.org/confluence/display/~aaronz/]
> Sakai Fellow - [http://aaronz-sakai.blogspot.com/]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20090326/8a0edfb0/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2437 bytes
Desc: not available
Url : http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20090326/8a0edfb0/attachment-0001.bin 