OK, in that case when there's a 2.0 ready to go, we'd also support 1.latest for (some indefinite but non-zero period of time).
You've convinced me, +1! On Wed, May 08, 2013 at 06:33:43PM +0100, Robert Newson wrote: > 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 -- Joan Touzet | [email protected] | wohali everywhere else
