Open Stack

On Fri, Aug 4, 2017 at 3:09 PM, Kevin L. Mitchell <klmitch at mit.edu> wrote:
> On Fri, 2017-08-04 at 14:52 -0700, Morgan Fainberg wrote:
>> > Maybe not, but please do recall that there are many deployers out
>> > there
>> > that track master, not fixed releases, so we need to take that
>> > level of
>> > compatibility into account.
>> >
>>
>> I am going to go out on a limb and say that we should not assume that
>> if code merges ever it is a contract because someone might be
>> following master. The contract should be for releases. We should do
>> everything we can to avoid breaking people, but in the case of an API
>> contract (behavior) that was never part of a final release, it should
>> be understood this may change if needed until it is released.
>>
>> This is just my $0.002 as this leads rapidly to "why bother having
>> real releases" if everything is a contract, let someone take a
>> snapshot where they're happy with the code to run. You're devaluing
>> the actual releases.
>
> In my view, following master imposes risks that deployers should
> understand and be prepared to mitigate; but I believe that it is our
> responsibility to acknowledge that they're doing it, and make a
> reasonable effort to not break them.  There are, of course, times when
> no reasonable effort will avoid breaking them, and in those cases, I
> feel that the reasonable course of action is to try to notify them of
> the upcoming breakage.  That's why then I went on to suggest that
> fixing this problem in keystone shouldn't require a version bump in
> this case: it _is_ a breakage that's being fixed.

I appreciate that this specific case you view as being in that
category, I was commenting more on the general case. I would go so far
as to outline exactly what we wont break for markers in-between
releases rather than what you've implied. I can come up with exactly
one case that should never be broken between releases (fixes that
change no behavior but address edge cases are fine): DB Schemas.

I am going to continue to say we cannot and should not commit to
treating anything that lands as a contract, it devalues the release
and ability of the developers to make shifts while working on a
release.

You and I may not agree here, but tracking master has risks and we
should allow for projects to make API changes for un-released APIs as
they see fit without version bumps.

Thanks for the feedback for this fix in specific, I think we came to
much the same conclusion in IRC but wanted some outside eyes on it.

Cheers,
--Morgan