Open Stack

Quoting Sean McGinnis (2018-05-31 09:54:46)
> 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.
> 

We are what we test.

We don't test upgrading from one commit to the next. We test upgrading
from the previous stable release. And as such, that's what has to keep
working.

So no, a revert shouldn't ever be subject to "oh no somebody may have
deployed this and you don't revert the db change". That's definitely a
downstream consideration and those who CD things have ways of detecting
and dealing with this on their end. That said, it would be nice if
developers consider this corner case, and try not to make it a huge
mess to unwind.