Those concerns of yours came from my post (probably). I'd just like to
explain. Obviously no one is going to purposely not test thrift as we go
forward, and hopefully thrift users will gain benefits from future
releases in terms of performance and the like. The core cassandra devs
i've worked with have all been fantastic about it and are tremendous
folks.
However, it's just human behaviour that if a group of devs are focused
on making (A) better, faster, more feature-full, the less time is spent
focused on (B). (B) is relegated to did we break (B)?, and hopefully
some testing is done days before a release is about to go out. This
maintenance mode thought process isn't something developers are usually
very good at. So as new releases come out, the better (A) will be, and
unfortunately, most times (B) gets worse unfortunately. In my experience
once you decide not to actively develop something it starts rotting
almost immediately, and it's caveat emptor for folks who want to use it
going forward. (This is really unrelated to cassandra, but development
in general). IMO it is better to just make the cut, so that you can
focus entirely on what the future plan is, and gain significant velocity
in development because of it.
Of course that is just my opinion, which in this case won't be taken.
Cassandra will still maintain compatibility for Thrift going forward.
I'd suggest it would be in the Thrift supporters best interest (even
more so now) to do early pre-release testing and get involved early.
dave
---
<br type="_moz" />
On 2014-03-26 11:15, Chris Burroughs wrote:
FWIW even for new development we have found thrift preferable to CQL.
Others have have a different experience and that's cool. It's
certinaly made it less intimidating to new users when explaining
Cassandra.
I'm very concerned at the sentiments in this thread about not testing
or upgrading to 2.1 being a "dumb" idea. The thing we value most from
Cassandra is that it works. Operability, stability, and robustness
are by far the most important traits. I can deal with wrapping APIs
and transport layers. Dealing with untested releases is much more
complicated.
