Mailing-List: contact users-help@trafficserver.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@trafficserver.apache.org
Received-SPF: error (nike.apache.org: local policy)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII
Subject: Re: [PROPOSAL] New release process
From: James Peach <jpeach@apache.org>
In-reply-to: <51E61F39-CBF4-470F-8B2A-9165CC518F5B@apache.org>
Date: Mon, 12 Aug 2013 14:03:36 -0700
Cc: "dev@trafficserver.apache.org" <dev@trafficserver.apache.org>
Message-id: <E01267AC-5D39-4239-9BD4-4369B38EDC7A@apache.org>
References: <DD11424D-D5B1-427D-B657-6A1B9A1E4024@apache.org>
 <2182FE65-9DFE-44EC-98D5-195959C9AFC2@apache.org>
 <54212A27-A7D3-45C4-AD62-F91F4834DF6D@apache.org>
 <5611395D-03D8-458C-A1E6-31CAFD4814CF@apache.org>
 <FCA6AA94-F254-4744-9B51-578D1E19F3E2@apache.org>
 <5C9E6790-8448-445B-BBB5-8A69EE0BB56D@apache.org>
 <51E61F39-CBF4-470F-8B2A-9165CC518F5B@apache.org>
To: users@trafficserver.apache.org

On Aug 12, 2013, at 1:56 PM, Leif Hedstrom <zwoop@apache.org> wrote:

> On Aug 12, 2013, at 2:28 PM, James Peach <jpeach@apache.org> wrote:
> 
>> On Aug 12, 2013, at 12:56 PM, Leif Hedstrom <zwoop@apache.org> wrote:
>> 
>>> On Aug 12, 2013, at 1:32 PM, James Peach <jpeach@apache.org> wrote:
>>> 
>>>> 
>>> 
>>> 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.
>> 
>> I don't think that a fast release cycle can work without strong compatibility guarantee. Who wants to deal with upgrade issues 3 or 4 times a year? The only way everyone will feel comfortable upgrading is if it a no-brainer and always works.
> 
> Why do they have to be exclusive? The proposal suggested basically:
> 
> 	- <n> number of releases per year, where compatibility is guaranteed. We can make n=4, that's good.
> 	- Once a year (or whatever, it doesn't specify), we allow to break compatibility.
> 
> 
> So, it would be safe for people to upgrade through the incremental releases (just as has been the case for all stable releases so far). Once a year, or whatever, we have the option to make an incompatible release. That doesn't mean we *have* to make an incompatible release. We'd bump major version if/when such a release gets made (my suggestions was to aim for no more than 1/ year).
> 
> The downside is that it can be up to 1 year before an incompatible change gets into a release. I personally think that's a reasonable compromise, if it can save a humongous amount of headache to try to provide automatic migrations through every release.

Ok, I think that we are saying the same thing then.

> 
> Does anyone other than me and James and Reindl have an opinion here? :-)
> 
> -- Leif