On 05/31/2018 03:50 AM, Thierry Carrez wrote:
Right... There might be a reasonable middle ground between "every
commit on master must be backward-compatible" and "rip out all
testing" that allows us to routinely revert broken feature commits (as
long as they don't cross a release boundary).
To be fair, I'm pretty sure that's already the case: we did revert
feature commits on master in the past, therefore breaking backward
compatibility if someone started to use that feature right away. It's
the issue with implicit rules: everyone interprets them the way they
want... So I think that could use some explicit clarification.
[ This tangent should probably gets its own thread to not disrupt the
no-nitpicking discussion ]
Just one last one on this, then I'm hoping this tangent ends.
I think what Thierry said is exactly what Dims and I were saying. I'm
not sure how that turned into
the idea of supporting committing broken code. The point (at least mine)
was just that we should
not have the mindset that HEAD~4 committed something that we realize was
not right, so we
should not have the mindset that "someone might have deployed that
broken behavior so we
need to make sure we don't break them." HEAD should always be
deployable, just not treated like
an official release that needs to be maintained.
__________________________________________________________________________
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
