Bug fixes only matter if they get to the user
It’s probably obvious to most of you that fixing an eat-your-files bug is worthy of an immediate release. But any bug that blocks the release from getting to your users is also worthy of an immediate release. This is true even if the bug is minor by itself. While it’s tempting to think that users will always install the latest updates as soon as they’re available, we know that’s not true.
The lead developer of a package I use recently posted to the mailing list to remind everyone to update from the .0 version. The initial release of the latest major version has a bug that can cause deletion of operating system files when removing a plugin. That seems bad. Unfortunately, the .2 version introduced an error in the package that causes it to be uninstallable on Fedora Linux.
The package error is already fixed and awaits the .3 release. The developer has a few more things they wanted to include that aren’t ready yet. So the fix waits.
The end result is that I can’t update the package through a regular software update. Of course, there are ways around this. I possess the skills to install from source, or via Pip, or download the .1 RPM to avoid the scary bug, or even create my own RPM that doesn’t have the packaging bug. But just because I can, that doesn’t mean everyone can.
For a certain subset of users, they’re stuck with this potentially file-erasing bug if they missed the .1 upgrade. Knowing that the eat-your-files bug is out there, I’d argue that releasing a .3 with the packaging fix — even if it’s the only change in the release — is the best course of action. Anything that was holding back the .3 release can drop to the .4 release. In this particular case, the .1 and .2 releases were less than a week apart. It would be easy for someone to install .0 just before .1 came out and not update until after .2 reached the repository.
I intentionally don’t mention the project here because the point isn’t to call them out specifically. It’s a great project by volunteer developers who do tremendous work in both software and community. But it represents the broader point that I wanted to make.
This post’s featured photo by Neringa Hünnefeld on Unsplash.
