Last updated May 10, 2011.
After you make an official release, sometimes you discover a bug that you want to immediately fix. Maybe you forgot to add the git release tag to all of the files in your project before you made the release node, and now the downloadable packaging is missing some files. Or perhaps, a last-minute change to an SQL query ended up breaking your module's support for PostgreSQL, but you didn't test that before you made the release. Maintainers might find themselves wishing they could move the git tag for their release, and start generating new packages from the new revisions of the affected files, but retain the same version number.
However, modifying a release after it exists is intentionally prevented by the release system. Once you release something, it's out in public and you can not take it back. Even if it just went out on the web, someone might have already downloaded it, or checked it out from git, and deployed it. It would be too confusing if once something was released, its contents might change without having a new unique version number. That's a large part of what made the old release "system" so difficult and confusing.
Once you make a release the only way to fix a problem is to make a new release that includes the fix.
Of course, users of your contribution will start to get annoyed if a new official release comes out every day for minor fixes, or whenever a major new release comes out, another release follows hours or days later, which actually works. So, it's always a good idea to test an official release as thoroughly as possible before you create the release node and publish your release to the world. Maintainers should also consider making "beta" releases of their modules, if they want more input and testing from their community of users. Normally, maintainers should "batch" bug fixes in groups, and only make another official release once enough smaller things, or a few big things, are fixed. However, certain critical bugs and any security vulnerabilities warrant a new official release immediately, even if the last official release was a day (or potentially even hours) before.
Comments
Marking a release as "pointless" or "not recommended" ?
This new policy does make sense, but there is one small change to it that could make it more pleasant to work with.
Situation:
There is a stable 1.0 version out there, and the maintainer creates a new 1.1 release with new features.
But, wait, the 1.1 release is not properly tested! The maintainer decides that people should continue to use 1.0 and NOT upgrade to 1.1. But removing the 1.1 is not possible, for obvious reasons.
So, the maintainer does a 1.2 release, that reverts back to the state of 1.0. Now the evil 1.1 is removed from the module page - finally!
Now some people will inevitably think they need to upgrade to 1.2, when in fact there is absolutely no point to it.
Would it be possible to make a setting on a release, indicating that it is pointless or even dangerous to upgrade?
The desired effect:
- Noone should ever consider to upgrade to 1.1
- People with 1.0 installed don't waste their time upgrading to 1.2, but wait for 1.3 instead.
- People who upgraded to 1.1 are encouraged to upgrade to 1.2 (because downgrading might bring other difficulties).