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

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@... 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@... 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@...
http://collab.sakaiproject.org/mailman/listinfo/sakai-dev

TO UNSUBSCRIBE: send email to
sakai-dev-unsubscribe@... with a subject of
"unsubscribe"




--
Aaron Zeckoski (aaronz@...)
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@...
http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe@...
with a subject of "unsubscribe"

_______________________________________________
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"


    

_______________________________________________
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"