Is an accidentally reverted feature a release blocker?
In your release process, you evaluate bugs that can potentially block the release (see chapter 11 of Program Management for Open Source Projects or posts on this site for more). Eventually, you’ll probably face this question: should we block the release to restore a feature that was reverted by accident? The answer, as usual, is “maybe!” You should have a policy in place, and it needs to be more sophisticated than “yes” or “no”.
Context matters a lot. The first thing to consider is whether or not the upcoming release is a major release or a bugfix release. Removing a feature (whether on purpose or by accident) in a bugfix release is generally a bad idea. On the other hand, users expect changes in features across major release boundaries.
You should also consider how much your user base relies on that feature — or if they even notice it. If the reversion means that something under the hood works differently in a way that the user probably won’t notice, then it’s probably not a blocker. If it renders the software unsuitable for the primary use case, then it’s a blocker. Of course, you should have release criteria that cover that functionality anyway.
And that’s probably the best way to approach it. When adding a new feature, decide if it should be release blocking or not. Write a release criterion that covers how the software should or should not behave with that feature. If the reversion causes the behavior to violate your release criteria, then of course it’s a blocker. If not, you can probably live without it for this release.
