On 28 April 2011 00:55, Eric Evans <eev...@rackspace.com> wrote: > On Tue, 2011-04-26 at 14:44 +0100, Stephen Connolly wrote: >> * I have given the CQL driver jar the same version number as >> everything else, because it is only going to work with the 0.8.0-beta1 >> jars anyway. >> >> Please vote (see >> http://www.apache.org/foundation/voting.html#ReleaseVotes) >> >> +1: Go ahead and release it >> 0: I have some issues with the release >> -1: I have something I think merits re-spinning this release > > -1 > > Why are we making up a different version number for the client code? >
1. because that version of the driver has a hard dependency on the other two jars, and because it is still in tree, therefore it is released in sync. 2. I cannot release another 1.0.0 artifact as you cannot overwrite versions in maven central. once you release a version it is released, so unless 0.8.0-beta2 comes with cql 1.0.1 then we are in trouble. You will literally have to increment the cql version for _every single release of the main jars_ or else I will have to make two sets of build targets one which releases cql only and the other which releases everything but cql. That is a messy release process to follow, but if that's what you want... from my PoV, there will be many issues releasing (oh why is this fix for cql not in the new release... yes it is... no it isn't... oh, somebody forgot to increment the cql version when doing the release and you are using maven central) unless you do one of several options: * move cql out of tree (so that it is released on its own schedule... we do this @maven for everything... many trees with many independent release schedules) * tie the cql version to the main tree version (what I did) * make the cql version a combo of the main and the cql version (i.e. 1.0.0-0.8.0-beta1) * keep cql in tree but make the build have two targets, 1st for everything but cql, 2nd for only cql (that will be a mess but it is a solution) We can bemoan Maven Central's policy (you can only release a specific version number once and only once), but that does not solve the issue that users want dependencies from a Maven repository, and Maven's architecture will not re-download a release version because of it's central assumption that releases do not change, so even if you could re-release a 1.0.0, anyone who used the old 1.0.0 would not get the new release (this is why -SNAPSHOTs are different from releases, Maven expects -SNAPSHOTs might change and will check for new versions... but you cannot put -SNAPSHOTs in a release repository) -Stephen > -- > Eric Evans > eev...@rackspace.com > >
