Return-Path: X-Original-To: apmail-couchdb-dev-archive@www.apache.org Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 7957199E7 for ; Tue, 21 May 2013 09:32:25 +0000 (UTC) Received: (qmail 30368 invoked by uid 500); 21 May 2013 09:32:25 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 30335 invoked by uid 500); 21 May 2013 09:32:25 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 30316 invoked by uid 99); 21 May 2013 09:32:24 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 21 May 2013 09:32:24 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW X-Spam-Check-By: apache.org Received-SPF: error (athena.apache.org: local policy) Received: from [80.244.253.218] (HELO mail.traeumt.net) (80.244.253.218) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 21 May 2013 09:32:19 +0000 Received: from [10.0.0.19] (91-66-82-235-dynip.superkabel.de [91.66.82.235]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.traeumt.net (Postfix) with ESMTPSA id AE2CA145AD for ; Tue, 21 May 2013 11:32:28 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: [DISCUSS] Release clean-up (delete ALL the branches!) From: Jan Lehnardt In-Reply-To: Date: Tue, 21 May 2013 11:31:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <290BAA7E-43E5-4993-8CA0-D8983BF0964A@apache.org> References: <68A781FC-9735-4FF0-BBB1-3828D96FC4B7@apache.org> <24857C82-2D18-4211-A33A-D25DC096EDFB@apache.org> To: dev@couchdb.apache.org X-Mailer: Apple Mail (2.1503) X-Virus-Checked: Checked by ClamAV on apache.org On May 21, 2013, at 08:32 , Benoit Chesneau wrote: > I thought we needed to support n and n-1. Did that change? It was my impression that that=92s 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=92t 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 -- >=20 > - beno=EEt > On May 21, 2013 3:43 AM, "Noah Slater" wrote: >=20 >> 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. >>=20 >>=20 >> On 20 May 2013 20:56, Jan Lehnardt wrote: >>=20 >>> Eh sorry, I just noticed that broke CI for 1.2.x which is surely = still an >>> actively supported branch, shouldn=92t we keep that around? >>>=20 >>> Jan >>> -- >>>=20 >>> On May 18, 2013, at 22:24 , Jan Lehnardt wrote: >>>=20 >>>>=20 >>>>=20 >>>> On 18.05.2013, at 19:56, Noah Slater wrote: >>>>=20 >>>>> 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. >>>>>=20 >>>>> 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. >>>>>=20 >>>>> Is this something I need to call another vote for, or am I free to = add >>> it? >>>>=20 >>>> Go for it. >>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 18 May 2013 18:50, Jan Lehnardt wrote: >>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On 18.05.2013, at 18:43, Noah Slater wrote: >>>>>>=20 >>>>>>> Unfortunately, the deed is done. What is your reason for wanting = to >>> keep >>>>>>> them around? >>>>>>=20 >>>>>> History :) >>>>>>=20 >>>>>> I have plenty of clones, so no worries :) >>>>>>=20 >>>>>> Jan >>>>>> -- >>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> On 18 May 2013 18:38, Jan Lehnardt wrote: >>>>>>>=20 >>>>>>>> Ah wow, that's what I get for going on vacation with unread >> threads. >>>>>>>>=20 >>>>>>>> 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. >>>>>>>>=20 >>>>>>>> Cheers >>>>>>>> Jan >>>>>>>> -- >>>>>>>>=20 >>>>>>>> On 11.05.2013, at 17:31, Noah Slater = wrote: >>>>>>>>=20 >>>>>>>>> Thanks guys. >>>>>>>>>=20 >>>>>>>>> All the Y.Y.x branches, with the exception of 1.3.x, have been >>> deleted. >>>>>>>>>=20 >>>>>>>>> The following releases have been archived: >>>>>>>>>=20 >>>>>>>>> * 1.0.4 >>>>>>>>> * 1.1.2 >>>>>>>>> * 1.2.1 >>>>>>>>> * 1.2.2 >>>>>>>>>=20 >>>>>>>>> (Where archived means: removed from our wiki and dist dir.) >>>>>>>>>=20 >>>>>>>>> I added the following to our CurrentReleases page: >>>>>>>>>=20 >>>>>>>>> CouchDB uses [[http://semver.org/|semantic versioning]], so, = in a >>>>>>>> nutshell: >>>>>>>>>=20 >>>>>>>>> * 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. >>>>>>>>>=20 >>>>>>>>> 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. >>>>>>>>>=20 >>>>>>>>> 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. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On 7 May 2013 19:34, Noah Slater wrote: >>>>>>>>>=20 >>>>>>>>>> Devs, >>>>>>>>>>=20 >>>>>>>>>> We're switching over to time-based releases. >>>>>>>>>>=20 >>>>>>>>>> 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. >>>>>>>>>>=20 >>>>>>>>>> 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. >>>>>>>>>>=20 >>>>>>>>>> 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. >>>>>>>>>>=20 >>>>>>>>>> If nobody objects in 72 hours, I will assume lazy consensus = and >>>>>> proceed. >>>>>>>>>>=20 >>>>>>>>>> ## 0.10.x line and before >>>>>>>>>>=20 >>>>>>>>>> Really old stuff. >>>>>>>>>>=20 >>>>>>>>>> Recommendation: >>>>>>>>>>=20 >>>>>>>>>> * Drop support of these release lines >>>>>>>>>> * Delete the branches >>>>>>>>>>=20 >>>>>>>>>> ## 0.11.x line >>>>>>>>>>=20 >>>>>>>>>> First release: March 2010 (three years old) >>>>>>>>>>=20 >>>>>>>>>> Unreleased changes: >>>>>>>>>>=20 >>>>>>>>>> * Fix for frequently edited documents in multi-master = deployments >>>>>> being >>>>>>>>>> duplicated in _changes and _all_docs. >>>>>>>>>>=20 >>>>>>>>>> Recommendation: >>>>>>>>>>=20 >>>>>>>>>> * Do not release these changes >>>>>>>>>> * Drop support of this release line >>>>>>>>>> * Delete the branch >>>>>>>>>>=20 >>>>>>>>>> ## 1.0.x line >>>>>>>>>>=20 >>>>>>>>>> First release: July 2010 (three years old) >>>>>>>>>>=20 >>>>>>>>>> No unreleased changes. >>>>>>>>>>=20 >>>>>>>>>> Recommendation: >>>>>>>>>>=20 >>>>>>>>>> * Drop support of this release line >>>>>>>>>> * Delete the branch >>>>>>>>>>=20 >>>>>>>>>> ## 1.1.x line >>>>>>>>>>=20 >>>>>>>>>> First release: July 2011 (two years old) >>>>>>>>>>=20 >>>>>>>>>> No unreleased changes. >>>>>>>>>>=20 >>>>>>>>>> Recommendation: >>>>>>>>>>=20 >>>>>>>>>> * Drop support of this release line >>>>>>>>>> * Delete the branch >>>>>>>>>>=20 >>>>>>>>>> ## 1.2.x line >>>>>>>>>>=20 >>>>>>>>>> First release: April 2012 (one year old) >>>>>>>>>>=20 >>>>>>>>>> No unreleased changes. >>>>>>>>>>=20 >>>>>>>>>> 1.3.x line is backwards compatible with 1.2.x. >>>>>>>>>>=20 >>>>>>>>>> Recommendation: >>>>>>>>>>=20 >>>>>>>>>> * Drop support of this release line >>>>>>>>>> * Delete the branch >>>>>>>>>>=20 >>>>>>>>>> ## 1.3.x line >>>>>>>>>>=20 >>>>>>>>>> First release: April 2013 (one month old) >>>>>>>>>>=20 >>>>>>>>>> Unreleased changes: >>>>>>>>>>=20 >>>>>>>>>> * Whatever bugfixes are on master or in branches right now. >>>>>>>>>>=20 >>>>>>>>>> Recommendation: >>>>>>>>>>=20 >>>>>>>>>> * Release 1.3.1 this month. >>>>>>>>>>=20 >>>>>>>>>> Thanks, >>>>>>>>>>=20 >>>>>>>>>> -- >>>>>>>>>> NS >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> -- >>>>>>>>> NS >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> -- >>>>>>> NS >>>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> -- >>>>> NS >>>=20 >>>=20 >>=20 >>=20 >> -- >> NS >>=20