Jenkins build is still unstable: Cassandra-Coverage #193

See

Re: major version release schedule

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

Re: major version release schedule

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

CQL support for compound columns

There has been a discussion taking place in CASSANDRA-2474[1] regarding the language and semantics of compound columns in CQL. Though the issue was only opened in July, and despite extended periods of inactivity, it is monstrously long. Additionally, the discussion necessarily includes inline visu

Re: major version release schedule

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

Build failed in Jenkins: Cassandra #1263

See Changes: [jbellis] merge #3335 from 1.0 -- [...truncated 2827 lines...] [junit] at org.apache.cassandra.service.InitClientTest.testInitClientStartup(InitClientTest.java:33) [junit]

Build failed in Jenkins: Cassandra-quick #186

See Changes: [jbellis] merge #3335 from 1.0 -- [...truncated 2166 lines...] [junit] at org.apache.cassandra.service.StorageService.initClient(StorageService.java:380) [junit] at

Re: major version release schedule

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

Re: 1.1 freeze approaching

Unless you need the new features, you don't need to upgrade. And the current version won't stop getting updates. As mentioned in the thread where the project moved to a 4 month major version cycle, smaller changes between major versions means they will be more stable. Even with the smaller cy

Re: major version release schedule

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

Re: major version release schedule

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

major version release schedule

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

Re: 1.1 freeze approaching

I like this part of that thread (w00t for a distributed test suite): > # Automate all tests > > I think the only way that we can keep people close to trunk and stay > stable is to build automated tests for *everything*. All code should > be exercised by thorough unit tests and distributed black-bo