On 28 April 2011 15:23, Eric Evans <eev...@rackspace.com> wrote: > 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. >
This version number is all about versioning the information in the __pom__. The pom defines transitive dependencies. You might not rebuild the cql jar at all, but keep redeploying with different poms (each getting their own version number... because we can only use a version number once)... yes that is somewhat wasteful of space on the central repository, but that's the way it works... [1] The 0.8.0-beta1 version number is only for the coordinates of the pom of cassandra-cql that will pull down the dependencies for using cql with cassandra 0.8.0-beta1. If that subtlety helps you understand the versioning I have chosen for the poms, well that is better. When the next release of cassandra hits, there may be a different tree of dependencies for cql, _even_if_you_don't_modify_a_single_cql_class_, in any case there will be different versions of the artifacts in the dependency tree, so, if you like, you need to release a new version of the dependency metadata for cql with every release of cassandra... at least until you remove the dependencies on cassandra core classes and probably the backing thrift transport. [1] we could do a more optimized space version where we have a shim jar (think manifest only) that is very small and pulls in the cassandra deps and the apache-cassandra-cql-1.0.0 jar but that does not really gain us much, we'd still be deploying a cql jar with every release... just not _the_ apache-cql-1.0.0.jar > > 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 > >
