cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Fortin <mi...@m410.us>
Subject Re: Cassandra 0.7.0 Release in Riptano public repository?
Date Tue, 11 Jan 2011 19:30:06 GMT
Thanks for your thoughtful and detailed replies Eric, it's much appreciated.

Mike

On Jan 11, 2011, at 11:23 AM, Eric Evans wrote:

> On Tue, 2011-01-11 at 09:23 -0500, Michael Fortin wrote:
>> This my understanding of 0.* releases.
>> - They're not considered production ready by the maintainers
>> - They subject to changes that break backwards compatibility
>> - Generally poorly documented because the api is so volatile
>> - Previous releases are unsupported
>> 
>> for 1.* releases
>> - The maintainer is saying this is tested and production ready,
>> sometimes also marked as Final for GA
>> - Minor releases do not break backward compatibility
>> - The major and minor release have some level of support, with open
>> source, that usually means docs and mailing lists but they should be
>> very active.  
>> - thoroughly documented
> 
> FWIW, your interpretation of what it means to be 1.0, is not wholly
> unique, but it's far from universal either.
> 
>> Sorting through the issue tracker is a little to fine grained to get a
>> big picture view of where cassandra is going.  
> 
> Sorry, I should have been more clear here.
> 
> The closest we have to a roadmap are the tickets that are marked as
> blocking the next release, you shouldn't have to do any digging, they're
> all available in one view here:
> 
> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310865&fixfor=12314820
> 
> But, it's pretty fluid for the first few months after a new release.
> 
>> And, just to be clear, I'm not questioning the maintainers approach,
>> just humbling asking for a little more clarification.  Cassandra is
>> awesome, and I'm itching to use it on some production projects where I
>> think it would be a great fit, but 0.* designation scares me a little.
>> Of course, a hastily released 1.* would be worse. 
> 
> I understand, but what I'm saying is a "1.0" release in this context
> carries special significance that just doesn't map well to open source
> projects.  And, in addition to being subjective, your criteria differs
> from that of many people.  It might make things easier to just version
> some future release 1.0 and be done with it, but I'd rather be honest
> with you.
> 
> This is honest:
> 
> * We treated the Google code dump in 2008 as 0.1.0 (though no formal
> release was made).
> * We likewise treated the Apache code dump in 2009 as 0.2.0 (again, no
> formal release).
> * We called the first release under the Apache Incubator 0.3.0.
> * We just now released 0.7.0.
> * We maintain backward compatibility between the "minor" and "revision",
> that is 0.6.1, 0.6.2, 0.6.3, etc.
> 
> This is why I said my preference would be to just drop the leading 0.
> We've been using the minor like a major, and the revision like a minor,
> (and we haven't had need for a revision).  We've had 7 major releases,
> (5 if you only want to count what's happened under Apache).
> 
> Also:
> 
> * Most of the "maintainers" would tell you that it is production-ready,
> but then, they might be biased since most of them are running it in
> production. YMMV.
> * It is as poorly documented as most FLOSS projects.
> * We provide support through the issue tracker, mailing lists, and IRC,
> and you can purchase support contracts through Riptano.
> 
> 
> -- 
> Eric Evans
> eevans@rackspace.com
> 


Mime
View raw message