cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kai Wang <dep...@gmail.com>
Subject Re: [RELEASE] Apache Cassandra 3.1 released
Date Thu, 10 Dec 2015 17:26:34 GMT
Josh,

Thank you very much for the clarification.

On Thu, Dec 10, 2015 at 11:13 AM, Josh McKenzie <jmckenzie@apache.org>
wrote:

> 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 <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
>> 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 <pauloricardomg@gmail.com>
>> 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 <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 planned release numbers.
>>>>
>>>> > The 3.0.2 will only contain bugfixes, while 3.2 will introduce new
>>>> features.
>>>>
>>>>
>>>>
>>>
>>
>

Mime
View raw message