aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: Aries release version policy
Date Tue, 29 May 2012 22:53:44 GMT
On Tuesday, May 29, 2012 10:57:24 PM Holly Cummins wrote:
> [moved from another email thread]
> 
> [snip]
> 
> On Tue, May 29, 2012 at 8:09 PM, Daniel Kulp <dkulp@apache.org> wrote:
> > On Tuesday, May 29, 2012 07:57:05 PM Holly Cummins wrote:
> > Well, the main reason is that it actually allows the SNAPSHOTs of things
> > like blueprint and transaction and such that we deploy to the snapshot
> > repository to actually be usable.     Without the change, you cannot
> > build things like Karaf/trunk (which uses those snapshots right now)
> > without first building Aries locally.   More in a sec.....
> 
> I think we're always going to have a need to sometimes use SNAPSHOT
> versions of the parent poms, if only while we try out new parent
> features before releasing those parents.

Using snapshot versions of parent poms is OK as long as the snapshot 
versions are deployable into Nexus as well.  I COULD have change the parent 
versions in all of the poms to 1.0.1-SNAPSHOT to match the new numbers and 
that would have worked from a Karaf standpoint.  However, I thought that 
just using 1.0.0 would be easier for you as you prepare for the 1.0.0 
releases of everything.  The only issue is having a SNAPSHOT of a version 
that has been released.   That is something we cannot have.

> >> (http://aries.apache.org/development/releasingaries.html) says:
> > No, you CANNOT have snapshots for a released version.  This is a
> > Maven/Nexus thing.
> > 
> >> "take the default for the first two questions, and set the new
> >> development version to be the same as the one you are releasing! This
> >> is because you don't know whether the next version released from the
> >> trunk will have a major, minor or micro version number change - you
> >> won't know until those changes are made! - so leave it for the person
> >> making those changes to make the decision and move to module-new
> >> version-SNAPSHOT."
> > 
> > OK.  This needs to change.  This won't work as Nexus won't allow those
> > snapshots to be at all usable or downloadable.
> 
> I guess we''ll need another way of indicating v.next which is more
> Nexus-friendly, and we'll need to update the release instructions. We
> could use an eye-catcher, like 1.42.42?
 
I personally prefer just the x.y.(z+1) notation for the SNAPSHOT  (1.0.0 -> 
1.0.1-SNAPSHOT) and trust that if a developer does something more than a 
patch compatible change they would update it to 1.1.0-SNAPSHOT or similar.  
Alternatively, if we DON'T trust the developers, update it to x.(y+1).0.  At 
release time, do a more thorough check.   Either way is fine by me.   I just 
generally tend to trust people more.  :-)

Dan




> 
> Holly
> 
> > Dan
> > 
> >> Normally the pre-release version wouldn't have been 1.0.0-SNAPSHOT, so
> >> that's partly my fault - when I did the pre-release work in the
> >> branch, I changed the versions to 1.0.0 ones, since otherwise not much
> >> would have been done in the branch!
> >> 
> >> Could we please revert revision 1343766 to align with our release
> >> policy and fix the build breaks?
> >> 
> >> Holly
> >> 
> >> 
> >> 
> >> 
> >> On Tue, May 29, 2012 at 5:46 PM, Apache Jenkins Server
> >> 
> >> <jenkins@builds.apache.org> wrote:
> >> > See <https://builds.apache.org/job/Aries/changes>
> > 
> > --
> > Daniel Kulp
> > dkulp@apache.org - http://dankulp.com/blog
> > Talend Community Coder - http://coders.talend.com
-- 
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com


Mime
View raw message