trafficserver-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leif Hedstrom <zw...@apache.org>
Subject Re: [PROPOSAL] New release process
Date Mon, 12 Aug 2013 20:56:20 GMT
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.

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

-- Leif
Mime
View raw message