Return-Path: X-Original-To: apmail-trafficserver-users-archive@www.apache.org Delivered-To: apmail-trafficserver-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 68B59100A3 for ; Thu, 15 Aug 2013 15:31:18 +0000 (UTC) Received: (qmail 26951 invoked by uid 500); 15 Aug 2013 15:30:54 -0000 Delivered-To: apmail-trafficserver-users-archive@trafficserver.apache.org Received: (qmail 26184 invoked by uid 500); 15 Aug 2013 15:30:42 -0000 Mailing-List: contact users-help@trafficserver.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@trafficserver.apache.org Delivered-To: mailing list users@trafficserver.apache.org Received: (qmail 26156 invoked by uid 99); 15 Aug 2013 15:30:39 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 15 Aug 2013 15:30:39 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [176.9.94.134] (HELO mail.brainsware.org) (176.9.94.134) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 15 Aug 2013 15:30:35 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.brainsware.org (Postfix) with ESMTP id 222A92055A; Thu, 15 Aug 2013 15:30:14 +0000 (UTC) Received: from mail.brainsware.org ([127.0.0.1]) by localhost (mail.brainsware.org [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id JgykLVXa50zY; Thu, 15 Aug 2013 15:30:11 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.brainsware.org (Postfix) with ESMTP id 6F1762055E; Thu, 15 Aug 2013 15:30:11 +0000 (UTC) X-Virus-Scanned: amavisd-new at brainsware.org Received: from mail.brainsware.org ([127.0.0.1]) by localhost (mail.brainsware.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id s3vReUVCw8U8; Thu, 15 Aug 2013 15:30:11 +0000 (UTC) Received: from mail.brainsware.org (mail.brainsware.org [176.9.94.134]) by mail.brainsware.org (Postfix) with ESMTP id 3C7EC204EF; Thu, 15 Aug 2013 15:30:11 +0000 (UTC) Date: Thu, 15 Aug 2013 15:30:10 +0000 (UTC) From: Igor =?utf-8?Q?Gali=C4=87?= To: dev@trafficserver.apache.org Cc: users@trafficserver.apache.org Message-ID: <1891713982.18846.1376580610977.JavaMail.zimbra@brainsware.org> In-Reply-To: References: <952461986.14074.1376343608272.JavaMail.zimbra@brainsware.org> <1349156592.14243.1376349011067.JavaMail.zimbra@brainsware.org> Subject: Re: [PROPOSAL] New release process MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_18845_1256250577.1376580610976" X-Originating-IP: [91.130.91.84] X-Mailer: Zimbra 8.0.4_GA_5737 (ZimbraWebClient - GC28 (Linux)/8.0.4_GA_5737) Thread-Topic: New release process Thread-Index: +g7f1/hGxWadXsXDkHPU77ey8pF3lA== X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_18845_1256250577.1376580610976 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I think enough time on this has passed that we can call everyone to review = the current draft in the wiki:=20 https://cwiki.apache.org/confluence/display/TS/New+Release+Processes=20 and perhaps also (re?)read about Semantic Versioning, which our proposal is= very tightly coupled with:=20 http://semver.org/=20 if this current proposal is clear and uncontroversial enough, we could move= on to deciding about specifics, such as which version to start with, how t= o handle the transition in Jira, and which of the currently released branch= es should be considered LTS, etc..=20 So long,=20 i=20 ----- Original Message ----- > On Mon, Aug 12, 2013 at 5:40 PM, Leif Hedstrom < zwoop@apache.org > wrote= : > > On Aug 12, 2013, at 5:10 PM, Igor Gali=C4=87 < i.galic@brainsware.org >= wrote: >=20 > > https://cwiki.apache.org/confluence/display/TS/New+Release+Processes >=20 > > > >=20 > > > >=20 > > > This was exactly my problem at first. Leif was going with his proposa= l in > > > one big zwoop from odd/even (-dev/stable) major.minor.patch releases = to > > > *just* major.minor releases (he's fixed that bit in the wiki by now) >=20 > > > >=20 > > Yes, I restored the major.minor.micro version concept. Sorry for > > obfuscating > > the issue unnecessarily. The updated proposals are still on >=20 > > From what I can gather, the issue of contention is how to deal with > > incompatible changes. We're all in violent agreement that our long stan= ding > > rule of not breaking compatibility within stable releases through the y= ear > > is a given (e.g. 3.2.0 to v3.2.1 should always be safe). >=20 > > Cheers, >=20 > > -- Leif >=20 > I talked with Leif about this in person and I may be coming around to the > idea. > The versioning would follow http://semver.org/ . The PATCH version would > essentially be used to do the version burn on a bad release vote and also > for the LTS versions before the next MAJOR release. The LTS release (whic= h > is a new wrinkle Leif mentioned and I added to the wiki) would be somethi= ng > the more conservative amongst us. Those who chose to run LTS could test t= he > other releases as if they were new feature dev releases leading up to the > next LTS release. The more adventurous would run the MINOR updates as the= y > came out quarterly. It's kinda like the best of both worlds in a way. > We just need to make sure to keep Alan committing on the > incompatible-next-major-release branch. :) --=20 Igor Gali=C4=87=20 Tel: +43 (0) 664 886 22 883=20 Mail: i.galic@brainsware.org=20 URL: http://brainsware.org/=20 GPG: 6880 4155 74BD FD7C B515 2EA5 4B1D 9E08 A097 C9AE=20 ------=_Part_18845_1256250577.1376580610976 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I think enough time on this has passed that we can call everyone= to review the current draft in the wiki:


and perhaps also (re?)read about Semantic Versioning, which our propo= sal is very tightly coupled with:


= if this current proposal is clear and uncontroversial enough, we could move= on to deciding about specifics, such as which version to start with, how t= o handle the transition in Jira, and which of the currently released branch= es should be considered LTS, etc..

So long,
<= div>
i

On Mon, Aug 12, = 2013 at 5:40 PM, Leif Hedstrom <zwoop@apache.org> wrote:
<= div class=3D"gmail_extra">
On Aug 12, 2013, at 5:10 P= M, Igor Gali=C4=87 <i.galic@brainsware.org> wrote:
  https://cwiki.apache.org/confluence/dis= play/TS/New+Release+Processes
>
>
> This was exactly my problem at first. Leif was going with his proposal= in one big zwoop from odd/even (-dev/stable) major.minor.patch releases to= *just* major.minor releases (he's fixed that bit in the wiki by now)
>

Yes, I restored the major.minor.micro version concept. Sorry for obfu= scating the issue unnecessarily. The updated proposals are still on

       


>From what I can gather, the issue of contention is how to deal with incompa= tible changes. We're all in violent agreement that our long standing rule o= f not breaking compatibility within stable releases through the year is a g= iven (e.g. 3.2.0 to v3.2.1 should always be safe).

Cheers,

-- Leif


I talked with Leif = about this in person and I may be coming around to the idea.

The versioning would= follow http://semver.org/= . The PATCH version would essentially be used to do the version burn on= a bad release vote and also for the LTS versions before the next MAJOR rel= ease. The LTS release (which is a new wrinkle Leif mentioned and I added to= the wiki) would be something the more conservative amongst us. Those who c= hose to run LTS could test the other releases as if they were new feature d= ev releases leading up to the next LTS release. The more adventurous would = run the MINOR updates as they came out quarterly. It's kinda like the best = of both worlds in a way.

We just nee= d to make sure to keep Alan committing on the incompatible-next-major-relea= se branch. :)



--
Igor Gali=C4=87

Tel: +43 (0) 664 886 2= 2 883
Mail: i.galic@brainsware.org
URL: http://brainsware.org/
GPG= : 6880 4155 74BD FD7C B515  2EA5 4B1D 9E08 A097 C9AE

------=_Part_18845_1256250577.1376580610976--