Return-Path: X-Original-To: apmail-cassandra-user-archive@www.apache.org Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 35DC5189F8 for ; Thu, 10 Dec 2015 16:13:23 +0000 (UTC) Received: (qmail 76089 invoked by uid 500); 10 Dec 2015 16:13:20 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 76054 invoked by uid 500); 10 Dec 2015 16:13:20 -0000 Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@cassandra.apache.org Delivered-To: mailing list user@cassandra.apache.org Received: (qmail 76045 invoked by uid 99); 10 Dec 2015 16:13:20 -0000 Received: from mail-relay.apache.org (HELO mail-relay.apache.org) (140.211.11.15) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 10 Dec 2015 16:13:20 +0000 Received: from mail-wm0-f48.google.com (mail-wm0-f48.google.com [74.125.82.48]) by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with ESMTPSA id BA0141A0338 for ; Thu, 10 Dec 2015 16:13:19 +0000 (UTC) Received: by mail-wm0-f48.google.com with SMTP id v187so40810894wmv.1 for ; Thu, 10 Dec 2015 08:13:19 -0800 (PST) X-Gm-Message-State: ALoCoQnk9OUEAfmq9nq0TTirL3dMjjAmzeskHSl435rdIOCdU6ptcuIVY8aSIwfPJBGnPTnT83UEUzWAgdc0qGIePps7pBp3OGbua4VOkDDY62ykreypsxc= MIME-Version: 1.0 X-Received: by 10.194.222.195 with SMTP id qo3mr13734172wjc.51.1449763998366; Thu, 10 Dec 2015 08:13:18 -0800 (PST) Received: by 10.28.22.7 with HTTP; Thu, 10 Dec 2015 08:13:18 -0800 (PST) In-Reply-To: References: <0741C62B-0CF1-4D52-96B1-F5C91F12BC1A@ecyrd.com> <25F79FF9-AFB9-4664-A19E-C2D03B9E2CE3@gmail.com> Date: Thu, 10 Dec 2015 11:13:18 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RELEASE] Apache Cassandra 3.1 released From: Josh McKenzie To: user@cassandra.apache.org Content-Type: multipart/alternative; boundary=001a11c3babe21adce05268d7c25 --001a11c3babe21adce05268d7c25 Content-Type: text/plain; charset=UTF-8 Kai, > The most stable version will be 3.1 because it includes the critical fixes > in 3.0.1 and some additional bug fixes 3.0.1 and 3.1 are identical. This is a unique overlap specific to 3.0.1 and 3.1. To summarize, the most stable version should be x.Max(2n+1).z. Going forward, you can expect the following: 3.2: new features 3.3: stabilization (built on top of 3.2) 3.4: new features 3.5: stabilization (built on top of 3.4) And in parallel (for the 3.x major version / transition to tick-tock transition period only): 3.0.2: bugfixes only 3.0.3: bugfixes only 3.0.4: bugfixes only etc *Any bugfix that goes into 3.0.X will be in the 3.X line, however not all bugfixes in 3.X will be in 3.0.X* (bugfixes for new features introduced in 3.2, 3.4, etc will obviously not be back-ported to 3.0.X). So, for the 3.x line: - If you absolutely must have the most stable version of C* and don't care at all about the new features introduced in even versions of 3.x, you want the 3.0.N release. - If you want access to the new features introduced in even release versions of 3.x (3.2, 3.4, 3.6), you'll want to run the latest odd version (3.3, 3.5, 3.7, etc) after the release containing the feature you want access to (so, if the feature's introduced in 3.4 and we haven't dropped 3.5 yet, obviously you'd need to run 3.4). This is only going to be the case during the transition phase from old release cycles to tick-tock. We're targeting changes to CI and quality focus going forward to greatly increase the stability of the odd releases of major branches (3.1, 3.3, etc) so, for the 4.X releases, our recommendation would be to run the highest # odd release for greatest stability. Hope that helps clarify. On Thu, Dec 10, 2015 at 10:34 AM, Kai Wang wrote: > Paulo, > > Thank you for the examples. > > So if I go to download page and see 3.0.1, 3.1 and 3.2. The most stable > version will be 3.1 because it includes the critical fixes in 3.0.1 and > some additional bug fixes while doesn't have any new features introduced in > 3.2. In that sense 3.0.1 becomes obsolete as soon as 3.1 comes out. > > To summarize, the most stable version should be x.Max(2n+1).z. > > Am I correct? > > > On Thu, Dec 10, 2015 at 6:22 AM, Paulo Motta > wrote: > >> > Will 3.2 contain the bugfixes that are in 3.0.2 as well? >> >> If the bugfix affects both 3.2 and 3.0.2, yes. Otherwise it will only go >> in the affected version. >> >> > Is 3.x.y just 3.0.x plus new stuff? Where most of the time y is 0, >> unless there's a really serious issue that needs fixing? >> >> You can't really compare 3.0.y with 3.x(.y) because they're two different >> versioning schemes. To make it a bit clearer: >> >> Old model: >> * x.y.z, where: >> * x.y represents the "major" version (eg: 2.1, 2.2) >> * z represents the "minor" version (eg: 2.1.1, 2.2.2) >> >> New model: >> * a.b(.c), where: >> * a represents the "major" version (3, 4, 5) >> * b represents the "minor" version (3.1, 3.2, 4.1, etc), where: >> * if b is even, it' a tick release, meaning it can contain both >> bugfixes and new features. >> * if b is odd, it's a tock release, meaning it can only contain >> bugfixes. >> * c is a "subminor" optional version, which will only happen in >> emergency situations, for example, if a critical/blocker bug is discovered >> before the next release is out. So we probably won't have a 3.1.1, unless a >> critical bug is discovered in 3.1 and needs urgent fix before 3.2. >> >> The 3.0.x series is an interim stabilization release using the old >> versioning scheme, and will only receive bug fixes that affects it. >> >> 2015-12-09 18:21 GMT-08:00 Maciek Sakrejda : >> >>> I'm still confused, even after reading the blog post twice (and reading >>> the linked Intel post). I understand what you are doing conceptually, but >>> I'm having a hard time mapping that to actual planned release numbers. >>> >>> > The 3.0.2 will only contain bugfixes, while 3.2 will introduce new >>> features. >>> >>> >>> >> > --001a11c3babe21adce05268d7c25 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Kai,
=C2=A0
The most stable version will be 3.1 because it incl= udes the critical fixes in 3.0.1 and some additional bug fixes
3.0.1 and 3.1 are identical. This is a unique overlap specific = to 3.0.1 and 3.1.

To summarize, the most stable version should be x.Max(2n+1).z.=
Going forward, you can expect the following:
3.2: new features
3.3: stabilization (built on top of 3.= 2)
3.4: new features
3.5: stabilization (built on t= op of 3.4)

And in parallel (for the 3.x major vers= ion / transition to tick-tock transition period only):
3.0.2: bug= fixes only
3.0.3: bugfixes only
3.0.4: bugfixes only
etc

Any bugfix that goes into 3.0.X wil= l be in the 3.X line, however not all bugfixes in 3.X will be in 3.0.X = (bugfixes for new features introduced in 3.2, 3.4, etc will obviously not b= e back-ported to 3.0.X).

So, for the 3.x line:
  • If you absolutely must have the most stable version of C* an= d don't care at all about the new features introduced in even versions = of 3.x, you want the 3.0.N release.
  • If you want access to the new f= eatures introduced in even release versions of 3.x (3.2, 3.4, 3.6), you'= ;ll want to run the latest odd version (3.3, 3.5, 3.7, etc) after the relea= se containing the feature you want access to (so, if the feature's intr= oduced in 3.4 and we haven't dropped 3.5 yet, obviously you'd need = to run 3.4).

This is only going to b= e the case during the transition phase from old release cycles to tick-tock= . We're targeting changes to CI and quality focus going forward to grea= tly increase the stability of the odd releases of major branches (3.1, 3.3,= etc) so, for the 4.X releases, our recommendation would be to run the high= est # odd release for greatest stability.
=C2=A0
Hope t= hat helps clarify.

On Thu, Dec 10, 2015 at 10:34 AM, Kai Wang &= lt;depend@gmail.com> wrote:
Paulo,

Thank you for the examples.

So= if I go to download page and see 3.0.1, 3.1 and 3.2. The most stable versi= on will be 3.1 because it includes the critical fixes in 3.0.1 and some add= itional bug fixes while doesn't have any new features introduced in 3.2= . In that sense 3.0.1 becomes obsolete as soon as 3.1 comes out.

To summarize, the most stable version should be x.Max(2n+1).z.
<= br>
Am I correct?


On Thu, Dec 10, 2015 at 6:22 AM, Paulo Motta <pauloricardomg@= gmail.com> wrote:
> Will 3.2 contain the bugfixes that are i= n 3.0.2 as well?

If the bugfix affects both 3.2 and 3.= 0.2, yes. Otherwise it will only go in the affected version.

> Is 3.x.y just=20 3.0.x plus new stuff? Where most of the time y is 0, unless there's a= =20 really serious issue that needs fixing?

You can't really = compare 3.0.y with 3.x(.y) because they're two different versioning sch= emes.=C2=A0 To make it a bit clearer:

Old model:
* x.y.z, where:
=C2=A0 * x.y represents the "major= " version (eg: 2.1, 2.2)
=C2=A0 * z represents the "= ;minor" version (eg: 2.1.1, 2.2.2)

New mo= del:
* a.b(.c), where:
=C2=A0 * a represents th= e "major" version (3, 4, 5)
=C2=A0 * b represents t= he "minor" version (3.1, 3.2, 4.1, etc), where:
= =C2=A0=C2=A0=C2=A0 * if b is even, it' a tick release, meaning it can c= ontain both bugfixes and new features.
=C2=A0=C2=A0=C2=A0 * i= f b is odd, it's a tock release, meaning it can only contain bugfixes.<= br>
=C2=A0 * c is a "subminor" optional version, which = will only happen in emergency situations, for example, if a critical/blocke= r bug is discovered before the next release is out. So we probably won'= t have a 3.1.1, unless a critical bug is discovered in 3.1 and needs urgent= fix before 3.2.

The 3.0.x series is an interim stabiliza= tion release using the old versioning scheme, and will only receive bug fix= es that affects it.

2015-12-09 18:21 GMT-08:00 Maciek Sakrejd= a <maciek@heroku.com>:
I'm still confused, even after reading the blog post= twice (and reading the linked Intel post). I understand what you are doing= conceptually, but I'm having a hard time mapping that to actual planne= d release numbers.

> The 3.0.2 will only contain bugfixes,= while 3.2 will introduce new features.





--001a11c3babe21adce05268d7c25--