I'm +1 on 1.3.0 being the upgrade back for 1.2.anything in general. If we stick with semver this is the expected path.
On 8 May 2013 18:26, Noah Slater <[email protected]> wrote: > *Noodles a little while longer...* > > In fact, I am not even sure why we recently did that 1.2.2 release. > Unfortunately, I think we got into the habit of thinking that minor version > numbers mean breaking changes. Because, in the past, this has sometimes > been the case. For those people who wanted that fix in the 1.2.2, I should > have said "please upgrade to 1.3". Unless there are breaking changes that I > do not know about? (If there is, please tell me. There is nothing in NEWS > or CHANGES that I can see.) > > What are your thoughts on this? > > > On 8 May 2013 18:06, Joan Touzet <[email protected]> wrote: > >> I don't know what the Apache stance is on things, but I'm -1 on deleting >> the 1.2.x branch. "n and n-1" support is fairly common, unless you want >> to consdier n == HEAD and n-1 == 1.3.x. >> >> Otherwise +1. >> >> -Joan >> >> On Tue, May 07, 2013 at 07:34:14PM +0100, Noah Slater wrote: >> > Devs, >> > >> > We're switching over to time-based releases. >> > >> > I took a moment to review our existing release branches today, and I have >> > prepared a list of recommendations for you. Please review these and give >> me >> > feedback. >> > >> > By "drop support" I mean "make official" and while this is ostensibly the >> > case for a few of these, what I _really_ mean is "delete the branch". I >> see >> > no reason to keep this stuff around. It would make my life a lot easier >> if >> > we could clean this stuff up. >> > >> > I'm not a Git expert, so I am relying on someone to sanity check this. >> > Remember: if we ever want to patch up a security issue in an unsupported >> > release, we will be issuing a patch. So I am assuming what we'll want to >> do >> > is patch against the last tag for that release line. No need for the >> branch >> > at all as far as I can tell. >> > >> > If nobody objects in 72 hours, I will assume lazy consensus and proceed. >> > >> > ## 0.10.x line and before >> > >> > Really old stuff. >> > >> > Recommendation: >> > >> > * Drop support of these release lines >> > * Delete the branches >> > >> > ## 0.11.x line >> > >> > First release: March 2010 (three years old) >> > >> > Unreleased changes: >> > >> > * Fix for frequently edited documents in multi-master deployments being >> > duplicated in _changes and _all_docs. >> > >> > Recommendation: >> > >> > * Do not release these changes >> > * Drop support of this release line >> > * Delete the branch >> > >> > ## 1.0.x line >> > >> > First release: July 2010 (three years old) >> > >> > No unreleased changes. >> > >> > Recommendation: >> > >> > * Drop support of this release line >> > * Delete the branch >> > >> > ## 1.1.x line >> > >> > First release: July 2011 (two years old) >> > >> > No unreleased changes. >> > >> > Recommendation: >> > >> > * Drop support of this release line >> > * Delete the branch >> > >> > ## 1.2.x line >> > >> > First release: April 2012 (one year old) >> > >> > No unreleased changes. >> > >> > 1.3.x line is backwards compatible with 1.2.x. >> > >> > Recommendation: >> > >> > * Drop support of this release line >> > * Delete the branch >> > >> > ## 1.3.x line >> > >> > First release: April 2013 (one month old) >> > >> > Unreleased changes: >> > >> > * Whatever bugfixes are on master or in branches right now. >> > >> > Recommendation: >> > >> > * Release 1.3.1 this month. >> > >> > Thanks, >> > >> > -- >> > NS >> >> -- >> Joan Touzet | [email protected] | wohali everywhere else >> > > > > -- > NS
