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 <[email protected]> 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 > >> > >> <[email protected]> wrote: > >> > See <https://builds.apache.org/job/Aries/changes> > > > > -- > > Daniel Kulp > > [email protected] - http://dankulp.com/blog > > Talend Community Coder - http://coders.talend.com -- Daniel Kulp [email protected] - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
