for you and then have to specify all the versions yourself. I haven't
cases they never have a .z). It just seems a little inconsistent to
me.
> 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@...
>
http://collab.sakaiproject.org/mailman/listinfo/sakai-dev>
> TO UNSUBSCRIBE: send email to
sakai-dev-unsubscribe@... with a subject of "unsubscribe"
>