Re: Cassandra 0.7.0 Release in Riptano public repository?

[Rauan Maemirov <ra...@maemirov.com>]

When I try `rpm -i riptano-release-5-1.el6.noarch.rpm`, it just freeze. Does
repository work?

2011/1/12 Michael Fortin <mi...@m410.us>

> 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
> >
>
>