Stabilization is the process of getting a release branch into a releasable state; that is, of deciding which changes will be in the release, which will not, and shaping the branch content accordingly.
There’s a lot of potential grief contained in that word, “deciding”. The last-minute feature rush is a familiar phenomenon in collaborative software projects: as soon as developers see that a release is about to happen, they scramble to finish their current changes, in order not to miss the boat. This, of course, is the exact opposite of what you want at release time. It would be much better for people to work on features at a comfortable pace, and not worry too much about whether their changes make it into this release or the next one. The more changes one tries to cram into a release at the last minute, the more the code is destabilized, and (usually) the more new bugs are created.
…
Thus, the process of stabilizing a release is mostly about creating mechanisms for saying “no”.
— Karl Fogel, Producing Open Source Software
I remember it well. So much better now.
Ah – it’s the very man who created and implemented those mechanisms!
The man from Toronté – he says No…