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 <dep...@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 <pauloricard...@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 <mac...@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. >>> >>> >>> >> >
