[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. If this breaks Karaf, I guess we'll need to come up with a solution. One solution might just be that we say a local Aries build of parent is needed to populate the maven repo. Another reasonable option (which you suggested in October) is to populate the relativePath element for the parents iff we're using a SNAPSHOT. > >> Since our >> build instructions >> (http://aries.apache.org/development/buildingaries.html) state that >> the way to build Aries is to build the parent first, I'm not sure >> being able to build without building parent first is urgent enough >> that it was worth destabilising the build for. I know we've discussed >> being able to build without building the parent first before >> (http://mail-archives.apache.org/mod_mbox/aries-dev/201111.mbox/%3C1129562 >> [email protected]%3E), and I can see that building without >> building parent first is nice. Maybe this is an issue we should come back >> to once the build is >> stabilised. > > This is only partially for this reason. It's mostly to get the deployed > snapshots to actually be usable for other projects to continue testing them. > Nexus does NOT allow a snapshot version of a released artifact. In our > case, the "nightly" deploy build would deploy a 1.0.0-SNAPSHOT version of > the parents, but Nexus' daily cleanup would then wipe them out and all the > other snapshots that are deployed are then useless. > > >> I also have a concern about revision 1343766, which is also included >> in this build. The version numbers of the current parent poms have >> been moved to 1.0.1-SNAPSHOT, when they should be 1.0.0-SNAPSHOT. This >> is a bit confusing, since they were 1.0.0-SNAPSHOT before the release. >> However, our release policy >> (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? 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 >
