[Building Sakai] 2.6.x pom <version> after 2.6.0 release
Anthony Whyte
arwhyte at umich.edu
Fri Mar 27 06:23:40 PDT 2009
Beyond the issue of patch pain and the ease with which one should be
able to do an svn update on a branch without some crazy incrementing
versioning pattern for my poms getting in the way (which, I am not
against), I think it is important to bear in mind that it is a risky
assumption (and will remain a risky assumption whatever versioning
guidelines we adopt) to assume that one can add (or should be able to
add) contrib projects to a Sakai build without first ensuring that
the base poms of each contrib project points to the correct Sakai
parent pom.
If today I take the head of 2.5.x branch (version M2) and then drop
in two well-managed contrib projects, Mneme 1.2m2 and QNA 1.0 (or
QNA 2.5.x) without first confirming the parent pom to which these
contrib project expects to bind, will I achieve a successful Maven
build? Nope.
So the idea that deployers can avoid or ignore some sort of manual or
programmatic intervention when combining core and contrib projects
into a new build because we choose a non-incrementing versioning
scheme, is I think unrealistic.
Cheers,
Anthony
On Mar 27, 2009, at 5:08 AM, Stephen Swinsburg wrote:
> A minor comment on the branch version being out of date, bear in
> mind the branch DOES stay the same, theoretically identical. No API
> changes, UI changes or tool behaviours should change, unless they
> are bugfixes. So the constant version of the branch is still valid
> as it really is only one version, just with bugfixes.
>
> That being said, if the version in contrib projects can be set to
> an official release with the appropriate maven repo definition
> setup, like you said David, then this whole problem could go away.
> This is where we need some "Guidelines for Contrib projects" perhaps.
>
>
> regards,
> Steve
>
>
>
> On 27/03/2009, at 8:24 AM, David Horwitz wrote:
>
>> Hi Guys,
>>
>> A couple of thoughts - I'm generally against the idea of the
>> branch version staying the same for the lifetime of the branch -
>> it leads to the version becoming devalued and introduces
>> increasing uncertainty about what version of a dependency your
>> project may actually be using. We need to remember that by the
>> standards of open source project our release cycles are long
>> (years), and that we're using the same version number to describe
>> a wide range of code of varying maturity and stability.
>>
>> On the issue that Seth mentioned about maintaining contrib
>> projects - there is no reason for 99.9% of contrib projects to
>> bind their versions to a non-release Sakai version. If you set
>> your Sakai version to a release (e.g. 2.5.3) and add the
>> definition of the Sakai maven repo to your projects base pom - it
>> will build and run for any 2.5.* version (and probably all 2.6
>> versions too)
>>
>> David
>>
>> Stephen Swinsburg wrote:
>>>
>>>
>>> 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/]
>>>
>>>
>>> _______________________________________________ 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"
>
More information about the sakai-dev
mailing list