You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cassandra.apache.org by Stephen Connolly <st...@apache.org> on 2011/04/26 15:44:17 UTC
[VOTE] Release Apache Cassandra 0.8.0-beta1 artifacts in Maven Central
Per the Apache release rules, only artifacts which have been voted on
can be released.
Thus, as I missed the main release vote, I cannot tag onto the end.
The artifacts I want to release are:
https://repository.apache.org/content/repositories/orgapachecassandra-114/
Notes:
* The tar.gz files are different from the main as the -src.tar.gz
includes my patch and the -bin.tar.gz has different timestamps on the
javadocs (previously I had just been reusing eric's tar.gz's and
hacking the patch to no overwrite them... but I think it is better to
have the actual source of what is used to generate all the artifacts
that make up this staging repo)
* 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
Vote will be open for 72 hours unless the PMC says we can finish
quicker and we have met the 3 or more binding +1's minimum
-Stephen
P.S. I do not have a binding vote at Cassandra, but here is my +1 anyway
Re: [VOTE] Release Apache Cassandra 0.8.0-beta1 artifacts in Maven Central
Posted by Stephen Connolly <st...@gmail.com>.
ping. still waiting for two more +1's from cassandra committers
- Stephen
---
Sent from my Android phone, so random spelling mistakes, random nonsense
words and other nonsense are a direct result of using swype to type on the
screen
On 29 Apr 2011 14:02, "Stephen Connolly" <st...@gmail.com>
wrote:
> OK CQL has been dropped from this release, I need two more binding +1's to
> release what remains (all & thrift)
>
> On 28 April 2011 20:42, Stephen Connolly <stephen.alan.connolly@gmail.com
>wrote:
>
>> ok well I will see about deleting it from the staging repo, can I get a
>> conditional + 1 on that basis?
>>
>> - Stephen
>>
>> ---
>> Sent from my Android phone, so random spelling mistakes, random nonsense
>> words and other nonsense are a direct result of using swype to type on
the
>> screen
>> On 28 Apr 2011 20:31, "Eric Evans" <ee...@rackspace.com> wrote:
>> > On Thu, 2011-04-28 at 16:44 +0100, Stephen Connolly wrote:
>> >> > 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.
>> >
>> > It sounds to me like you need to omit the CQL jar entirely then, and
not
>> > add it to Maven Central except as a different project.
>> >
>> > --
>> > Eric Evans
>> > eevans@rackspace.com
>> >
>>
Re: [VOTE] Release Apache Cassandra 0.8.0-beta1 artifacts in Maven Central
Posted by Stephen Connolly <st...@gmail.com>.
OK CQL has been dropped from this release, I need two more binding +1's to
release what remains (all & thrift)
On 28 April 2011 20:42, Stephen Connolly <st...@gmail.com>wrote:
> ok well I will see about deleting it from the staging repo, can I get a
> conditional + 1 on that basis?
>
> - Stephen
>
> ---
> Sent from my Android phone, so random spelling mistakes, random nonsense
> words and other nonsense are a direct result of using swype to type on the
> screen
> On 28 Apr 2011 20:31, "Eric Evans" <ee...@rackspace.com> wrote:
> > On Thu, 2011-04-28 at 16:44 +0100, Stephen Connolly wrote:
> >> > 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.
> >
> > It sounds to me like you need to omit the CQL jar entirely then, and not
> > add it to Maven Central except as a different project.
> >
> > --
> > Eric Evans
> > eevans@rackspace.com
> >
>
Re: [VOTE] Release Apache Cassandra 0.8.0-beta1 artifacts in Maven Central
Posted by Brandon Williams <dr...@gmail.com>.
On Mon, May 2, 2011 at 8:38 PM, Eric Evans <ee...@rackspace.com> wrote:
> On Thu, 2011-04-28 at 20:42 +0100, Stephen Connolly wrote:
>> ok well I will see about deleting it from the staging repo, can I get
>> a conditional + 1 on that basis?
+1
-Brandon
Re: [VOTE] Release Apache Cassandra 0.8.0-beta1 artifacts in Maven
Central
Posted by Eric Evans <ee...@rackspace.com>.
On Thu, 2011-04-28 at 20:42 +0100, Stephen Connolly wrote:
> ok well I will see about deleting it from the staging repo, can I get
> a conditional + 1 on that basis?
+1
--
Eric Evans
eevans@rackspace.com
Re: [VOTE] Release Apache Cassandra 0.8.0-beta1 artifacts in Maven Central
Posted by Stephen Connolly <st...@gmail.com>.
ok well I will see about deleting it from the staging repo, can I get a
conditional + 1 on that basis?
- Stephen
---
Sent from my Android phone, so random spelling mistakes, random nonsense
words and other nonsense are a direct result of using swype to type on the
screen
On 28 Apr 2011 20:31, "Eric Evans" <ee...@rackspace.com> wrote:
> On Thu, 2011-04-28 at 16:44 +0100, Stephen Connolly wrote:
>> > 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.
>
> It sounds to me like you need to omit the CQL jar entirely then, and not
> add it to Maven Central except as a different project.
>
> --
> Eric Evans
> eevans@rackspace.com
>
Re: [VOTE] Release Apache Cassandra 0.8.0-beta1 artifacts in Maven
Central
Posted by Eric Evans <ee...@rackspace.com>.
On Thu, 2011-04-28 at 16:44 +0100, Stephen Connolly wrote:
> > 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.
It sounds to me like you need to omit the CQL jar entirely then, and not
add it to Maven Central except as a different project.
--
Eric Evans
eevans@rackspace.com
Re: [VOTE] Release Apache Cassandra 0.8.0-beta1 artifacts in Maven Central
Posted by Stephen Connolly <st...@gmail.com>.
On 28 April 2011 15:23, Eric Evans <ee...@rackspace.com> wrote:
> On Thu, 2011-04-28 at 06:52 +0100, Stephen Connolly wrote:
>> On 28 April 2011 00:55, Eric Evans <ee...@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
> eevans@rackspace.com
>
>
Re: [VOTE] Release Apache Cassandra 0.8.0-beta1 artifacts in Maven
Central
Posted by Eric Evans <ee...@rackspace.com>.
On Thu, 2011-04-28 at 06:52 +0100, Stephen Connolly wrote:
> On 28 April 2011 00:55, Eric Evans <ee...@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
eevans@rackspace.com
Re: [VOTE] Release Apache Cassandra 0.8.0-beta1 artifacts in Maven Central
Posted by Stephen Connolly <st...@gmail.com>.
On 28 April 2011 00:55, Eric Evans <ee...@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
> eevans@rackspace.com
>
>
Re: [VOTE] Release Apache Cassandra 0.8.0-beta1 artifacts in Maven
Central
Posted by Eric Evans <ee...@rackspace.com>.
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?
--
Eric Evans
eevans@rackspace.com
Re: [VOTE] Release Apache Cassandra 0.8.0-beta1 artifacts in Maven Central
Posted by mck <mc...@apache.org>.
> Please vote
+1 (non-committer)
~mck
Re: [VOTE] Release Apache Cassandra 0.8.0-beta1 artifacts in Maven Central
Posted by Jonathan Ellis <jb...@gmail.com>.
+1
On Tue, Apr 26, 2011 at 8:44 AM, Stephen Connolly <st...@apache.org> wrote:
> Per the Apache release rules, only artifacts which have been voted on
> can be released.
>
> Thus, as I missed the main release vote, I cannot tag onto the end.
>
> The artifacts I want to release are:
>
> https://repository.apache.org/content/repositories/orgapachecassandra-114/
>
> Notes:
> * The tar.gz files are different from the main as the -src.tar.gz
> includes my patch and the -bin.tar.gz has different timestamps on the
> javadocs (previously I had just been reusing eric's tar.gz's and
> hacking the patch to no overwrite them... but I think it is better to
> have the actual source of what is used to generate all the artifacts
> that make up this staging repo)
> * 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
>
> Vote will be open for 72 hours unless the PMC says we can finish
> quicker and we have met the 3 or more binding +1's minimum
>
> -Stephen
>
> P.S. I do not have a binding vote at Cassandra, but here is my +1 anyway
>
--
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of DataStax, the source for professional Cassandra support
http://www.datastax.com
[RESULT] [VOTE] Release Apache Cassandra 0.8.0-beta1 artifacts in
Maven Central
Posted by Stephen Connolly <st...@gmail.com>.
This vote has passed:
+1: Jonathan Ellis (binding); Eric Evans (binding); Brandon Williams
(binding); mck (non-binding); Stephen Connolly (non-binding)
0:
-1:
I will promote the artifacts to Maven Central
-Stephen
On 26 April 2011 14:44, Stephen Connolly <st...@apache.org> wrote:
> Per the Apache release rules, only artifacts which have been voted on
> can be released.
>
> Thus, as I missed the main release vote, I cannot tag onto the end.
>
> The artifacts I want to release are:
>
> https://repository.apache.org/content/repositories/orgapachecassandra-114/
>
> Notes:
> * The tar.gz files are different from the main as the -src.tar.gz
> includes my patch and the -bin.tar.gz has different timestamps on the
> javadocs (previously I had just been reusing eric's tar.gz's and
> hacking the patch to no overwrite them... but I think it is better to
> have the actual source of what is used to generate all the artifacts
> that make up this staging repo)
> * 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
>
> Vote will be open for 72 hours unless the PMC says we can finish
> quicker and we have met the 3 or more binding +1's minimum
>
> -Stephen
>
> P.S. I do not have a binding vote at Cassandra, but here is my +1 anyway
>