On Aug 12, 2013, at 3:30 PM, Igor Galić <i.ga...@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
