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

[Anthony Whyte]

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]

That (dropping the revision) makes using the maven release plugin more
annoying since you can no longer just allow it to move things forward
for you and then have to specify all the versions yourself. I haven't
really seen this revision dropping used as a practice by other
projects (I have certainly seen projects only use x.y but in those
cases they never have a .z). It just seems a little inconsistent to
me.
-AZ


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"

[Seth Theriault]

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

[Steve Swinsburg-2]

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"

[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
>
>

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

[David Horwitz]

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"

[Aaron Zeckoski]

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

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

[David Horwitz]

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"

[Steve Swinsburg-2]

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@... 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"

[Anthony Whyte]

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@...> 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"

[Steve Swinsburg-2]

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@...

phone: [phone]

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@...> 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"

[Seth Theriault]

Steve Swinsburg wrote:

> 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.

The issue of how to set <sakai.version> in the 2.6.x maint
branch's master/pom.xml has been informally discussed at the
Conference.

A compromise position of:

<sakai.version>2.6-SNAPSHOT</sakai.version>

has surfaced as a solution affording harmony.

As a reminder of previous decisions and discussions, maintenance
releases would use their release version number and 2.6.x itself
will bind to a released, stable version of K1.

Comments?

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

[nfgrilo]

A compromise position of:
<sakai.version>2.6-SNAPSHOT</sakai.version>
has surfaced as a solution affording harmony.

Excellent!

This allows institutions to easily update their 2.6.x branch without having to update the sakai.version on every contrib and in-house developed tools...

 

As a reminder of previous decisions and discussions, maintenance
releases would use their release version number and 2.6.x itself
will bind to a released, stable version of K1.

Since kernel is a critical base module, it makes perfect sense to me.

Overall, +1.

Nuno

 

Comments?

Seth

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

--
Nuno Fernandes  [www.linkedin.com/in/nfgrilo]
Software Developer - UFP-UV  [Universidade Virtual]
Software Developer - Sakai Foundation  [sakaiproject.org]
Sakai Fellow 2008 - Sakai Foundation  [confluence.sakaiproject.org/confluence/x/FIF9AQ]

Universidade Fernando Pessoa  [www.ufp.pt]
Praça 9 de Abril, 349
4249-004 Porto
tel: + 351 22 507 13 00
fax: + 351 22 550 82 69

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