I've created a 1.1 branch in git. The freeze is on!
On Tue, Jan 10, 2012 at 2:59 PM, Jonathan Ellis wrote:
> I've tagged 7 tickets as "critical" [1] for 1.1. All of them deal
> with CQL; I strongly believe that 1.1 needs to be where CQL goes from
> being "the future" to being "the present." We
+1
Regards,
On Mon, Dec 19, 2011 at 9:56 AM, Jonathan Ellis wrote:
> Just a reminder that for us to meet our four-month major release
> schedule (i.e., 1.1 = Feb 18), we need to code freeze on Jan 18, which
> is just about a month away on the calendar but significantly closer in
> terms of m
+1
On Tue, Jan 10, 2012 at 11:30 PM, Jonathan Ellis wrote:
> On Tue, Jan 10, 2012 at 3:59 PM, Brandon Williams wrote:
>> On Tue, Jan 10, 2012 at 2:59 PM, Jonathan Ellis wrote:
>>> I've tagged 7 tickets as "critical" [1] for 1.1. All of them deal
>>> with CQL;
>>
>> Actually 1391 doesn't, but i
On Tue, Jan 10, 2012 at 3:59 PM, Brandon Williams wrote:
> On Tue, Jan 10, 2012 at 2:59 PM, Jonathan Ellis wrote:
>> I've tagged 7 tickets as "critical" [1] for 1.1. All of them deal
>> with CQL;
>
> Actually 1391 doesn't, but is quite important nonetheless.
The connection there is that if it w
On Tue, Jan 10, 2012 at 2:59 PM, Jonathan Ellis wrote:
> I've tagged 7 tickets as "critical" [1] for 1.1. All of them deal
> with CQL;
Actually 1391 doesn't, but is quite important nonetheless.
> All of these (with the exception of 3707, which is relatively quick)
> are in progress, and some (2
On Tue, Jan 10, 2012 at 2:59 PM, Jonathan Ellis wrote:
> I've tagged 7 tickets as "critical" [1] for 1.1. All of them deal
> with CQL; I strongly believe that 1.1 needs to be where CQL goes from
> being "the future" to being "the present." We've been promising this
> for almost a year now and it
I've tagged 7 tickets as "critical" [1] for 1.1. All of them deal
with CQL; I strongly believe that 1.1 needs to be where CQL goes from
being "the future" to being "the present." We've been promising this
for almost a year now and it's time to deliver.
All of these (with the exception of 3707, w
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
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
On Tue, Dec 20, 2011 at 12:45 AM, Radim Kolar wrote:
> can you make release cycle slower? its better to have more new features and
> do major upgrades less often. it saves time needed for testing and
> migrations.
http://www.mail-archive.com/dev@cassandra.apache.org/msg01549.html
-Brandon
Just a reminder that for us to meet our four-month major release
schedule (i.e., 1.1 = Feb 18),
can you make release cycle slower? its better to have more new features
and do major upgrades less often. it saves time needed for testing and
migrations.
11 matches
Mail list logo
