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 <klmi...@mit.edu>
signature.asc
Description: This is a digitally signed message part
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
