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 144EB10C6C for ; Mon, 12 Aug 2013 19:57:13 +0000 (UTC) Received: (qmail 15848 invoked by uid 500); 12 Aug 2013 19:57:12 -0000 Delivered-To: apmail-trafficserver-users-archive@trafficserver.apache.org Received: (qmail 15601 invoked by uid 500); 12 Aug 2013 19:57:11 -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 15573 invoked by uid 99); 12 Aug 2013 19:57:10 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 12 Aug 2013 19:57:10 +0000 X-ASF-Spam-Status: No, hits=0.0 required=5.0 tests= X-Spam-Check-By: apache.org Received-SPF: error (athena.apache.org: local policy) Received: from [71.6.165.248] (HELO kramer.ogre.com) (71.6.165.248) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 12 Aug 2013 19:57:03 +0000 Received: from [192.168.201.3] (homey.ogre.com [24.56.188.103]) (authenticated bits=0) by kramer.ogre.com (8.14.5/8.14.5) with ESMTP id r7CJuLHj032676 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 12 Aug 2013 12:56:22 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: [PROPOSAL] New release process From: Leif Hedstrom In-Reply-To: <5611395D-03D8-458C-A1E6-31CAFD4814CF@apache.org> Date: Mon, 12 Aug 2013 13:56:20 -0600 Cc: "dev@trafficserver.apache.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <2182FE65-9DFE-44EC-98D5-195959C9AFC2@apache.org> <54212A27-A7D3-45C4-AD62-F91F4834DF6D@apache.org> <5611395D-03D8-458C-A1E6-31CAFD4814CF@apache.org> To: users@trafficserver.apache.org X-Mailer: Apple Mail (2.1508) X-Virus-Checked: Checked by ClamAV on apache.org On Aug 12, 2013, at 1:32 PM, James Peach wrote: > On Aug 12, 2013, at 12:22 PM, Leif Hedstrom wrote: >=20 > Yes. The goal here is to make the release reliable and predictable so = that upgrading is not a scary experience or a lot of work. >=20 >>=20 >> Also, how do we deal with incompatibility changes? >=20 > Configurations and data formats should be automatically upgraded. = Everything would need to be release noted thoroughly. Wow, that's a humongous pain in the ass to deal with. I've done this = before (Mozilla) and it truly sucks big time to have to deal with this = :-/. Particularly dealing with live upgrading of the cache would be a = monumental task, and *incredibly* risky. I can right now say I'm hugely -1 on this idea. To put it bluntly, I = think we'd kill ourselves and the project if we tried. ;) >=20 >> Or are you proposing that we from now on, never make anything = incompatible? Incompatible he >> * An API needs to be deprecated (and removed) in order to fix / = change something significant. For example, the new cache key proposal = comes to mind. >=20 > Mark as deprecated, then remove once the support window has passed. But I'm missing something then. If there's a support window, you are = allowing incompatible changes? What does the support window define? "If = you are running a version older then months, we'll not support you = upgrading to this version" ? >=20 >> * New configuration file format(s). [This might be possible to = make compatible, by preserving all old config formats as well as the new = ones]. >=20 > Automatic upgrade tools. These upgrade tools runs as part of starting traffic_server every time = you start it ? Meaning, I deploy my old configs, and a new binary, and = suddenly the configs in the /etc/ directory are modified for me? That = seems like a non-starter already, considering that deployment state is = not the same as runtime state. If you mean providing tools that upgrades my configs, I make new config = packages, and push that in conjunction with a binary update, then that's = not compatible, right ? Compatible here would imply I can replace the = binaries only, and things will just magically work. >=20 >> * Remove the incompatibility branch and release cycle. There's = only master and the release branch. >> * Define hard release dates (say, 9/1/2013, 12/1/2013, 3/1/2013 = etc.) >>=20 >> Does that sum it up ? >=20 > Pretty much. I think the only way a rapid release cycle can work is if = there is confidence that upgrading never breaks. IMHO, this is a good = thing to have independent of the release process, but it's not = necessarily easy to achieve. I think that fixed release dates focus the = mind and make the process more predictable. I agree 100% that having backward compatibility can be nice. I think it = opens up an enormous can of worm, that will make our project impossible = to work with (but, that's just my biased, unscientific opinion, please = prove me wrong). This is why the proposal had the additional release = cycle for incompatible changes, with a longer release train (say, 1 / = year). I think the fixed dates is a very minor issue in comparison to the = compatibility ideas. I personally think it's a step in the wrong = direction (the rest of the OpenSource world is moving towards agile = methodologies), but I would not oppose fixed release dates if that's the = consensus of the community. It certainly does make the release process = predictable. Cheers, -- leif