[Building Sakai] 2.6.x pom <version> after 2.6.0 release
Steve Swinsburg
s.swinsburg at lancaster.ac.uk
Fri Mar 27 06:40:19 PDT 2009
I think I may have sent out a mixed message in my last post, so yes
beyond patch pain/incrementing poms, lets focus on the previous
suggestion for contrib projects:
1. Bind to a point release in your contrib project's base pom:
<parent>
<artifactId>base</artifactId>
<groupId>org.sakaiproject</groupId>
<version>2.5.4</version>
</parent>
2. Add the Sakai Maven repo to your base pom:
<repositories>
<repository>
<id>sakai-maven</id>
<name>Sakai Maven Repo</name>
<layout>default</layout>
<url>http://source.sakaiproject.org/maven2</url>
<snapshots>
<enabled>false</enabled>
</snapshots>
</repository>
</repositories>
3. Build in any 2.5 release.
This works. I can get my project, via this method, to build in Sakai
2.5.x ie M2. Maven downloads the necessary dependencies (ie the 2.5.4
versions) from the remote repository to build against. So long as they
are marked as 'provided' then they won't be deployed so you won't get
dupes in shared, and since I know that the API's are not going to
change between 2.5.1 and 2.5.2 and so on, I don't think this is too
risky.
I might be wrong though or this might be some bad practice, but IMO
and what Aaron mentioned before, people shouldn't have to edit POM's
to get a project to build.
cheers,
Steve
---
Steve Swinsburg
Portal Systems Developer
Centre for e-Science
Lancaster University
Lancaster
LA1 4YT
email: s.swinsburg at lancaster.ac.uk
phone: +44 (0) 1524 594870
On 27 Mar 2009, at 13:23, Anthony Whyte wrote:
> 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"
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20090327/1d3326c5/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/20090327/1d3326c5/attachment-0001.bin
More information about the sakai-dev
mailing list