On Fri, Aug 4, 2017 at 3:09 PM, Kevin L. Mitchell <klmi...@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 __________________________________________________________________________ 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
