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 21:53:00 GMT
On Aug 12, 2013, at 3:30 PM, Igor Galić <i.galic@brainsware.org> wrote:

> 
>> 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.
> 
> this ^

I'm not sure how we've ended up in this discussion, the above is a given, has always been,
always will be, and was never disputed.

1) We have never, ever broken compatibility within a major release. At least not intentionally,
I think we reverted one such change once?

2) The Wiki proposal as it was written would never, ever allow you to break compatibility
within the major release.


This was always understood, and nothing is changing here.


What the two proposal are about (as far as I can tell) is how to deal with incompatible changes.
My proposal was:

	"All incompatible changes can only be committed on the next major release branch, say 5.x.
Master is always backwards compatible until next major release."


Whereas James's proposal says:

	"Incompatible changes are allowed on Master at any time, but *only* if they are accompanied
with code that allows for a seamless and automatic upgrade path."


I'm not sure how the second proposal would deal with a situation where it's not possible to
provide such an automatic upgrade path, maybe it never happens :).

Cheers,

-- Leif


Mime
View raw message