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

[Anthony Whyte]

Seth, Steve--I don't think you will find such a recommendation other  
than the general one that there is value in keeping current with the  
releases or associated maintenance branch in order pick up the latest  
enhancements and fixes (particularly those that close security  
holes).   This I would say represents the Foundation recommendation.

Adopters are free to make their own choice with respect to what  
version or particular revision of Sakai to choose.   As I wrote below  
the 2.5 maintenance releases are regarded as more reliable than  
certain of the earlier series (based on feedback I have received) and  
one no longer needs to automatically advise adopters to choose the  
maintenance branch for their production instance as was common in the  
past.

As regards sakaiproject.org (SPO), my use of maintenance branch and  
contrib code does not run counter to any Foundation recommendation;  
indeed, I made what I think is the appropriate choice given that  SPO  
is a stripped down version of the 2.5 (e.g., no learning tools) that  
also uses a number of contrib tools (have a look at it's .externals  
in mSub).   So there is no backsliding or implementation hypocrisy  
here. :)

Patch pain is a legitimate concern, and one raised earlier by Steve,  
which is why I thought the conversation he and I started should be  
elevated to a list discussion (since I don't consider myself all- 
knowing).  I've never found updating parent pom references a big deal  
but then again my role in generating releases or maintaining SPO is  
not quite the same as overseeing bSpace, OnCourse, CTOOLS or a VULA  
build that may incorporate contrib code (unlike a general Sakai  
release) and are of a different scale than the more humble  
sakaiproject.org.  Of course, if we could better harmonize our  
versioning strategies between "core" Sakai and contrib code then the  
patch pain of which you speak would be a non-issue.

As for outside examples, the wicket example Steve provided is a good  
one.  Then again, as counter examples the Apache Maven, Jackrabbit,  
and Shindig projects use [major.minor.revision]-SNAPSHOT for their  
branch versioning; in other words, there may well be an Apache  
project that fits everyone's idea of a good naming convention.  We  
should choose ours on the basis of what works best for the way we do  
development and implementations.

Again, I am principally interested in consistency in the area of  
versioning.  If we can agree on a common versioning practice then I  
think we will be better off-especially if more Sakai projects choose  
in the future to perform their own releases.

Cheers,

Anth




On Mar 26, 2009, at 4:19 PM, Seth Theriault wrote:

> Anthony Whyte wrote:
>
>> 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).
>
> Pardon my ignorance and/or bad recollection, but can someone
> provide a Web page or message archive thread that states this
> recommendation? And does the Foundation intend to follow its own
> recommmendations given that www.sakaiproject.org appears to be
> running "Sakai 2.5.x" at the moment?
>
> Personally, despite the recent gains in making point releases
> under 2.5, I don't think this process is reliable enough to
> ensure timely releases (the future goal). I think the usual
> balance between "official imprimateur" and overall reliability is
> still in favor of the maintenance release for organizations that
> have the time, energy, and people to use it.
>
>> 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 versioning scheme complicates any attempt to build a
> non-"core" Sakai tool on a production system built with the
> maintenance branch. Many "contrib" authors are maintaining 2.5.x
> branches for their tools using "M2" as the version, which
> minimizes the "patch pain" that I and other have to go through
> when building new releases. If we were to adopt the
> "[major.minor.revision]-SNAPSHOT" practice for the 2.6.x branch,
> I would have to redo all the version-related patches every time
> someone does a point release and I use a rev number higher than
> that.
>
> Instead, I would propose that a maintenance branch use
> [major.minor.X] or [major.minor]-MAINT as its versions. These
> identify it correctly as the maintenance branch but ensure a
> consistent label for outside use.
>
> Seth
>
>