current stable

[Jeremy Hanna <je...@gmail.com>]

As 0.8 approaches final status in the next few weeks, I wondered about how releases receive the label, "current stable".  I don't know if there's any precedent for this, but I thought it might be nice to do a separate vote when new major releases are out and weigh heavily those in the community that can test the release against their use cases and perhaps client developers (probably a subset of the former).  So for example, 0.8 comes out and it is not labeled current stable until a separate vote has been taken and it can be verified by a good portion of those doing testing against it that it is in fact stable.

I know that changes were put into place to get releases out faster, but I think this change would be good so that "current stable" can have much more meaning to people.  It's hard enough to pick up a new technology that has a high learning curve without having to do testing on what is supposed to be stable.

Along with this, is it possible to separate out the releases in the apache debian repo as David Strauss suggested so that we can have a stable line and other labels for lines?

Anyway, just wanted to propose something be done so that there could be more credibility could be attached to current stable, and hopefully cassandra as a whole could gain a more positive reputation for being stable as a result (especially among new adopters).

Re: current stable

[Edward Capriolo <ed...@gmail.com>]

On Mon, Apr 25, 2011 at 12:53 PM, Jonathan Ellis <jb...@gmail.com> wrote:
> Back when I used to run postgresql, I saw the same cycle:
>
>  - most people don't bother testing until "stable" .0 is released
>  - consequently, most people don't deploy to production until .1 is released
>
> I think moving the stable label would be futile since the majority
> will just wait that much longer to test. We did 4 RCs for 0.7; I don't
> think another (by whatever name) would have made much difference.
>
> It's worth pointing out that 0.7 was an unusually big release with a
> correspondingly unusually high bug count.  We had a much easier time
> getting the four previous releases to gel, and we've deliberately
> limited 0.8 to a similar scope as those.
>
> On Mon, Apr 25, 2011 at 8:00 AM, Jeremy Hanna
> <je...@gmail.com> wrote:
>> As 0.8 approaches final status in the next few weeks, I wondered about how releases receive the label, "current stable".  I don't know if there's any precedent for this, but I thought it might be nice to do a separate vote when new major releases are out and weigh heavily those in the community that can test the release against their use cases and perhaps client developers (probably a subset of the former).  So for example, 0.8 comes out and it is not labeled current stable until a separate vote has been taken and it can be verified by a good portion of those doing testing against it that it is in fact stable.
>>
>> I know that changes were put into place to get releases out faster, but I think this change would be good so that "current stable" can have much more meaning to people.  It's hard enough to pick up a new technology that has a high learning curve without having to do testing on what is supposed to be stable.
>>
>> Along with this, is it possible to separate out the releases in the apache debian repo as David Strauss suggested so that we can have a stable line and other labels for lines?
>>
>> Anyway, just wanted to propose something be done so that there could be more credibility could be attached to current stable, and hopefully cassandra as a whole could gain a more positive reputation for being stable as a result (especially among new adopters).
>
>
>
> --
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder of DataStax, the source for professional Cassandra support
> http://www.datastax.com
>

I can agree that 0.7.X was a big complex release. However calling
0.7.1 and 0.7.2 "Generally Available" like mysql does might make more
sense. This would let a know that this version should be ready for
battle, but it has not be proven in that context yet. This would also
let the user make the concious choice to use the newer edgy version,
rather then turning that user into tester.

Re: current stable

[Jonathan Ellis <jb...@gmail.com>]

Back when I used to run postgresql, I saw the same cycle:

 - most people don't bother testing until "stable" .0 is released
 - consequently, most people don't deploy to production until .1 is released

I think moving the stable label would be futile since the majority
will just wait that much longer to test. We did 4 RCs for 0.7; I don't
think another (by whatever name) would have made much difference.

It's worth pointing out that 0.7 was an unusually big release with a
correspondingly unusually high bug count.  We had a much easier time
getting the four previous releases to gel, and we've deliberately
limited 0.8 to a similar scope as those.

On Mon, Apr 25, 2011 at 8:00 AM, Jeremy Hanna
<je...@gmail.com> wrote:
> As 0.8 approaches final status in the next few weeks, I wondered about how releases receive the label, "current stable".  I don't know if there's any precedent for this, but I thought it might be nice to do a separate vote when new major releases are out and weigh heavily those in the community that can test the release against their use cases and perhaps client developers (probably a subset of the former).  So for example, 0.8 comes out and it is not labeled current stable until a separate vote has been taken and it can be verified by a good portion of those doing testing against it that it is in fact stable.
>
> I know that changes were put into place to get releases out faster, but I think this change would be good so that "current stable" can have much more meaning to people.  It's hard enough to pick up a new technology that has a high learning curve without having to do testing on what is supposed to be stable.
>
> Along with this, is it possible to separate out the releases in the apache debian repo as David Strauss suggested so that we can have a stable line and other labels for lines?
>
> Anyway, just wanted to propose something be done so that there could be more credibility could be attached to current stable, and hopefully cassandra as a whole could gain a more positive reputation for being stable as a result (especially among new adopters).



-- 
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of DataStax, the source for professional Cassandra support
http://www.datastax.com