On Tue, May 29, 2012 at 8:09 PM, Daniel Kulp <[email protected]> wrote:
I wrote: [snip] >> Unfortunately, we now have fourteen test failures which will need to >> be fixed before 1.0.0 work can progress. > Dan wrote: > Except the tests actually PASS on my machine with the changes. That > certainly makes it difficult to figure out what's causing it. Likely > something more timing related, but I'm not really sure yet. Hi Dan, I'm sorry if my note was grumpy. I'm beginning to despair of ever getting green builds and getting the 1.0.0 release out the door. I'd assumed that things had worked for you locally for you if you'd delivered. The difficulty of figuring out what's causing the failures is what I was driving at with my comments about not delivering to a broken build. Because there were already test failures, it's harder to unpick what's going on with the latest batch of failures. It's also harder for Brian to fix the problems related to ARIES-832 if other tests are now breaking. I wasn't suggesting that you shouldn't have broken the build at all, since of course these things happen. (I'd be in a bit of a glass house, since I broke the build the other week too, again because things behaved differently on Jenkins.) Confusingly, build 1470 is back down to two failures, and the ARIES-858 changes delivered on 1470 should have improved concurrency but not changed any test results. I'm wondering if we're seeing some interaction between the artefacts produced by the Aries builds,or something subtle like that. I'll move the discussion of release version numbers to a new thread, since I think it's a broader issue. Holly > > >> Ironically, I've been waiting >> (for a week) for a clean build, so that I can deliver changes very >> similar to the ones which Dan's made >> (https://builds.apache.org/job/Aries/1469/changes). Dan's changes >> switch from using the snapshot parents to the released parents, which >> allows a build to be done without building parent first. > > 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..... So does this mean that we'll never be able to try out the latest version of the parent poms without doing a parent release before we switch to them? This doesn't seem ideal to me. However, I don't think I really understand the issue. What do you mean by 'allowing' SNAPSHOTs of blueprint? Do you mean download these snapshots from a repo, or build them as part of the build of another project? [snip] > > 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. > > 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 >
