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

Fri Mar 27 01:44:11 PDT 2009

This is a practice I follow for all my projects. It also has the
benefit that the project can be built without even requiring a
checkout of Sakai source code. In other words:

Download Sakai binary and extract (version 2.5.* - trunk)
checkout blogwow source
mvn clean install sakai:deploy
start Sakai

I still want to replace the source checkout and build with the idea of
using binary deployment but we are not there yet.
Still, I think everyone can see the value in the user never having to
touch a file just to try out a tool.
-AZ

On Fri, Mar 27, 2009 at 8:24 AM, David Horwitz <david.horwitz at uct.ac.za> 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"
>
> _______________________________________________
> 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/]