[openstack-dev] [keystone][api] Backwards incompatible changes based on config
Kevin L. Mitchell
klmitch at mit.edu
Fri Aug 4 22:09:01 UTC 2017
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.
Kevin L. Mitchell <klmitch at mit.edu>
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 205 bytes
Desc: This is a digitally signed message part
More information about the OpenStack-dev