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.
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 man-hours as people take holiday vacations.
I've taken a first stab at moving issu
12 matches
Mail list logo
