One welcome change is http://cassandra.apache.org/ actually starts displaying:
"Latest release *2.1.3* (Changes <http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/cassandra-2.1.3>), Stable release *2.0.12* (Changes <http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/cassandra-2.0.12>) " It's better than before where "Latest release" is the only link available on the home page and naturally that's most people download. On Thu, Feb 19, 2015 at 1:57 PM, Robert Coli <rc...@eventbrite.com> wrote: > On Wed, Feb 18, 2015 at 5:26 PM, Andrew <redmu...@gmail.com> wrote: > >> Let me know if I’m off base about this—but I feel like I see a lot of >> posts that are like this (i.e., use this arbitrary version, not this other >> arbitrary version). Why are releases going out if they’re “broken”? This >> seems like a very confusing way for new (and existing) users to approach >> versions... >> > > In my opinion and in no way speaking for or representing Apache Cassandra, > Datastax, or anyone else : > > I think it's a problem of messaging, and a mismatch of expectations > between the development team and operators. > > I think the "stable" versions are stable by the dev team's standards, and > not by operators' standards. While testing has historically been IMO > insufficient for a data-store (where correctness really matters) there are > also various issues which probably can not realistically be detected in > testing. Of course, operators need to be willing to operate (ideally in > non-production) near the cutting edge in order to assist in the detection > and resolution of these bugs, but I think the project does itself a > disservice by encouraging noobs to run these versions. You only get one > chance to make a first impression, as the saying goes. > > My ideal messaging would probably say something like "versions near the > cutting edge should be treated cautiously, conservative operators should > run mature point releases in production and only upgrade to near the > cutting edge after extended burn-in in dev/QA/stage environments." > > A fair response to this critique is that operators should know better than > to trust that x.y.0-5 release versions of any open source software are > likely to be production ready, even if the website says "stable" next to > the download. Trust, but verify? > > =Rob >
