+1 makes sense to me As far as I understand it, the odd numbered release number exist solely because the the C++ build system can't cope with non-numerical -SNAPSHOT or similar... so 0.21 is just a synonym for 0.22-SNAPSHOT
-- Rob On 22 November 2012 20:59, Robbie Gemmell <[email protected]> wrote: > Hi all, > > I recently made the nightly build of the Java tree that we run on Jenkins ( > > https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-Java-Artefact-Release/ > ) > start deploying our maven snapshot releases to the ASF snapshots repo ( > https://repository.apache.org/content/repositories/snapshots/). Since then > we have created the 0.20 release branch and I put a Jenkins job ( > > https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-Java-Artefact-Release-0.20/ > ) > in place to do a nightly snapshot deployment of that. > > Due to the above we have now stopped deploying 0.19 snapshots and started > deploying 0.20 and 0.21 snapshot artifacts. The result is that the 0.19 > snapshots will simply remain on the Nexus instance because we will never > deploy 0.19 release artifacts and the automated cleanup process will simply > leave them in place as a result. The same will happen to 0.21 snapshots > when we make the 0.22 branch. In addition to generally cluttering thigns > up, its also going to be annoying for anyone actually using the snapshots > since they wont necessarily be aware of the change and could just use the > stale output, or instead will just have to change their POMs twice (from > 0.19 snapshot to 0.20 snapshot, then 0.20 release). > > As such, unless there is strong objection I plan to tweak the build system > in the days ahead to simply avoid deploying the odd-numbered snapshots in > future, moving it to deploy 0.22 snapshots now (then 0.24 snapshots after > that) and cleaning the old 0.19 and 0.21 snapshots from the repo. > > Robbie >
