I think there are couple of different ideas here at play
1) Time to release
2) Quality of the release
IMO, the issue that effects most people is the quality of the release. So when
someone says that we should slow down the release cycles, I think what they
mean is that we should spend more tim
> Until recently we were working hard to reach a set of goals that
> culminated in a 1.0 release. I'm not sure we've had a formal
> discussion on it, but just talking to people, there seems to be
> consensus around the idea that we're now shifting our goals and
> priorities around some (usability,
On Tue, Dec 20, 2011 at 8:16 AM, Jonathan Ellis wrote:
> Nobody's forcing you to upgrade. If you want twice as much time
> between upgrading, just wait for 1.2. In the meantime, people who
> need the features in 1.1 also get those early (no, running trunk in
> production isn't a serious option).
Nobody's forcing you to upgrade. If you want twice as much time
between upgrading, just wait for 1.2.
Currently 1.0 branch is still less stable then 0.8, i still get OOM on
some nodes. Adding 1.1 feature set on top will make it less stable.
It's also worth noting that waiting for 2x as many f
Here is another thing to consider: There is considerable cost involved
in running/developing on old branches as the divergence between the
version you're running and trunk increases.
For those actively doing development, such divergence actually causes
extra work and slows down development.
A mor
On Tue, Dec 20, 2011 at 6:16 AM, Jonathan Ellis wrote:
> Nobody's forcing you to upgrade. If you want twice as much time
> between upgrading, just wait for 1.2. In the meantime, people who
> need the features in 1.1 also get those early (no, running trunk in
> production isn't a serious option).
Nobody's forcing you to upgrade. If you want twice as much time
between upgrading, just wait for 1.2. In the meantime, people who
need the features in 1.1 also get those early (no, running trunk in
production isn't a serious option). I don't see any real benefit for
you in forcing your preferenc
http://www.mail-archive.com/dev@cassandra.apache.org/msg01549.html
I read it but things are different now because magic 1.0 is out. If you
implement 1.0 and put it into production, you really do not want to
retest app on new version every 4 months and its unlikely that you will
get migration a
