On Thu, 2011-04-28 at 06:52 +0100, Stephen Connolly wrote: > 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.
Neither of those is a good reason. > 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... The likelihood that that driver won't receive even a minor bug fix (resulting in version 1.0.1) is low but not non-existent, so whatever the process, it shouldn't absolutely require that driver releases occur when Cassandra releases do. It sounds like that is your problem. > 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) Unlike the RPC, CQL is meant to be stable. It is a significant feature that you should be able to use the same version of a driver across many versions of Cassandra. This is why the versions must be different, so that you can evaluate each new driver version in the context of how it changed, not (necessarily )how Cassandra changed during some arbitrary release. I don't know if driver releases will be made in the time between Cassandra releases, but I suspect that at some point they probably will be. I don't that every driver will need to be released every time that Cassandra does, they probably won't. None of of this should prevent them all from living in the same tree. > 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) -- Eric Evans eev...@rackspace.com
