Meh. This works when you’re algolia and co and your “users” are developers. When your users are real users and you’re not dealing with web resources that can be live updated, a release is a big deal and shouldn’t be treated so blithely.

When we release a new version of a native desktop software, we are “owning” that release and taking responsibility for it. Our customers pay money for our products, and if someone (especially a new customer) we’re to download a broken build in that time, it will cause a much bigger headache than having to wait a bit for a release to go out.

There are two extremes, and this article switches between them: release early and break often, and release rarely but break nothing. For algolia to have shipped a broken release and have only one person that can release is the problem. Either a release is no big deal and everyone can release and it’s ok if a release is and, or a release is a really big deal and only select people can release to ensure the quality of releases.

The answer isn’t globally “make releasing easier,” it’s to decide which model best suits your company product, and embrace that. Either test your releases like crazy to make sure you don’t ship broken code, or make it easy and fast to fix a bad release.