An Example Module Release Strategy

Here is one developer's approach to branching and tagging contributed modules, and what it should communicate to users of that module. It is being shared here because dww has said it matches his thinking on the subject.

• No release, just a dev branch: Users should not use this unless they are helping develop or test this module.
• 1.0-UnstableX: Users probably should not use. The developer is still just throwing ideas around. The “Unstable” tag is pretty new, but seems to be replacing the old custom of releases with Major of 0.
• 1.0-AlphaX: Code moving to alpha means that the developer is serious about developing an idea. Techniques and API’s will be in constant flux, features are being added and removed, and bugs will crop up regularly. Users should still use this code at their own risk.
• 1.0-BetaX: Moving to beta means the developer feels like they have a solid approach. The API gels over this stage. Features are easily added in this stage, but removing features is a big deal. Techniques and implementation are still in flux underneath the API. Users should still use diligence in using this code on production sites. Many developers do not feel obligated to provide an upgrade path to changes made at this stage.
• 1.0-RCX: Moving to RC is a big deal. This signals that the API is fixed and should be reliable. Effort is focused on fixing bugs. Users should feel comfortable using an RC, but they should be prepared to do some testing on their own before jumping into production. Ideally strings are stable if anyone wants to start donating translations. RC is the trickiest phase and takes discipline. This is when the module starts getting more serious users and those users often provide valuable feedback and bring up new use cases. Often developers will have trouble resisting the urge to features in this stage. <Controversial> Any really big change at this stage should be signaled by a drop back from RC to Beta. </Controversial>
• 1.0: Yay, strings stable, bugs quashed, happy days.
• 1.X: Oops, someone found a bug, and there is a fix. In a 3 digit system, this would be labeled 1.0.1, but that is not supported by Drupal contrib. So the only real choice is to bump the patch level. Only small, safe tweaks are added along with bugfixes. This branch stays recommended, safe, and just gets more stable, while new features that need testing go into a new branch.
• 2.0-AlphaX: New features go here for testing. A 2.0-UnstableX release is possible if the developer is trying out a really radical change. The users are back to use-at-your-own-risk. The previous branch stays recommend until the new branch reaches 2.0-RC1, then the new RC is marked as recommended.