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 > eev...@rackspace.com >
