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

Fri Mar 27 01:51:57 PDT 2009

I have been wondering if in the K1 world it would be possible to build a
tool that only had a build dependency on the kernel. It seems that this
should be possible but haven't had time to look into it ...

D

Aaron Zeckoski wrote:
> 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"
>>
>>
>>     
>
>
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20090327/b0b88d22/attachment-0001.html 