On May 21, 2013, at 08:32 , Benoit Chesneau <[email protected]> wrote:
> I thought we needed to support n and n-1. Did that change? It was my impression that that’s what we agreed on, as well. While 1.2.x -> 1.3.x is the recommended upgrade line, we pledged to do bugfixes and security issues for 1.2.x. Especially given that the view engine got a bit of a revamp, I could conceive of a situation where users wouldn’t want to make the jump to 1.3.x just yet. In a post 1.3.x strict-semver, we should have less of that, but for now I think it is wise to keep 1.2.x up (that said, we can resurrect the branch at any time, so we may as well leave it out until needed). Jan -- > > - benoît > On May 21, 2013 3:43 AM, "Noah Slater" <[email protected]> wrote: > >> Nope. 1.2.x is no longer an actively supported branch. 1.3.x is forwards >> compatible, and is the recommended upgrade path for anyone on 1.2.x. >> >> >> On 20 May 2013 20:56, Jan Lehnardt <[email protected]> wrote: >> >>> Eh sorry, I just noticed that broke CI for 1.2.x which is surely still an >>> actively supported branch, shouldn’t we keep that around? >>> >>> Jan >>> -- >>> >>> On May 18, 2013, at 22:24 , Jan Lehnardt <[email protected]> wrote: >>> >>>> >>>> >>>> On 18.05.2013, at 19:56, Noah Slater <[email protected]> wrote: >>>> >>>>> Based on the decision made in this thread, it would like to add >>> something >>>>> to the release procedure about deleting old branches when we drop >>> support >>>>> for that release line. >>>>> >>>>> As far as I understand it, no history is lost. The tags still point to >>> what >>>>> we shipped, and the commits still exist in the repository We're just >>>>> removing the pointers to the tips of the branches. >>>>> >>>>> Is this something I need to call another vote for, or am I free to add >>> it? >>>> >>>> Go for it. >>>> >>>>> >>>>> >>>>> >>>>> On 18 May 2013 18:50, Jan Lehnardt <[email protected]> wrote: >>>>> >>>>>> >>>>>> >>>>>> On 18.05.2013, at 18:43, Noah Slater <[email protected]> wrote: >>>>>> >>>>>>> Unfortunately, the deed is done. What is your reason for wanting to >>> keep >>>>>>> them around? >>>>>> >>>>>> History :) >>>>>> >>>>>> I have plenty of clones, so no worries :) >>>>>> >>>>>> Jan >>>>>> -- >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> On 18 May 2013 18:38, Jan Lehnardt <[email protected]> wrote: >>>>>>> >>>>>>>> Ah wow, that's what I get for going on vacation with unread >> threads. >>>>>>>> >>>>>>>> I'm major -1 on deleting old release branches, but I'd be happy to >>> have >>>>>>>> them moved to an archived repository. For the time being, I'll keep >>>>>> them on >>>>>>>> my GitHub. >>>>>>>> >>>>>>>> Cheers >>>>>>>> Jan >>>>>>>> -- >>>>>>>> >>>>>>>> On 11.05.2013, at 17:31, Noah Slater <[email protected]> wrote: >>>>>>>> >>>>>>>>> Thanks guys. >>>>>>>>> >>>>>>>>> All the Y.Y.x branches, with the exception of 1.3.x, have been >>> deleted. >>>>>>>>> >>>>>>>>> The following releases have been archived: >>>>>>>>> >>>>>>>>> * 1.0.4 >>>>>>>>> * 1.1.2 >>>>>>>>> * 1.2.1 >>>>>>>>> * 1.2.2 >>>>>>>>> >>>>>>>>> (Where archived means: removed from our wiki and dist dir.) >>>>>>>>> >>>>>>>>> I added the following to our CurrentReleases page: >>>>>>>>> >>>>>>>>> CouchDB uses [[http://semver.org/|semantic versioning]], so, in a >>>>>>>> nutshell: >>>>>>>>> >>>>>>>>> * X.Y.Z equates to major version, minor version, and bugfix >> version. >>>>>>>>> * The major version will be incremented every time we make >> backwards >>>>>>>>> incompatible changes. >>>>>>>>> * The minor version will be incremented every time we add >> backwards >>>>>>>>> compatible features. >>>>>>>>> * The patch version will be incremented every time we add >> backwards >>>>>>>>> compatible fixes. >>>>>>>>> >>>>>>>>> We will support each major version for 12 months. So, if 1.0.0 was >>>>>>>> released >>>>>>>>> on 2010-01-01, then we would features and fixes to it until >>> 2011-01-01. >>>>>>>>> After 12 months have passed, we may continue to release fixes for >>>>>>>> critical >>>>>>>>> security issues, but these will be in the form of patches. >>>>>>>>> >>>>>>>>> Note that the upgrade path for minor versions is to update the >>> latest >>>>>>>> minor >>>>>>>>> version. We will not continue to release bugfix versions for an >> old >>>>>> minor >>>>>>>>> version. That is, 1.1.0 immediately supersedes 1.0.x, and no more >>> fixes >>>>>>>>> will be made on the 1.0.x line. Similarly, 1.2.0 immediately >>> supersedes >>>>>>>>> 1.1.x. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 7 May 2013 19:34, Noah Slater <[email protected]> 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 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> NS >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> NS >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> NS >>> >>> >> >> >> -- >> NS >>
