It is time to review my personal module release tagging strategy. The available tags have changed since I started releasing Drupal modules, and my understanding of the flow has evolved recently. Readers will understand this better if they are familiar with the info on the Drupal contrib branches and tags page.
Here is my current thinking (replace X with an increasing counter starting with 1):
- No release, just a dev: Don’t use this unless you are helping develop or test this module.
- 1.0-UnstableX: Probably should not use. Still just throwing ideas around. The “Unstable” tag is pretty new. I used to tag this stage with a Major number less than 1, but using “Unstable” seems more drupally.
- 1.0-AlphaX: Code moving to alpha means that I am 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. Still use at your own risk.
- 1.0-BetaX: Moving to beta means I feel like I 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.
- 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. I have a lot of trouble not adding features in this stage. My new plan is to drop back from RC to Beta if I choose to add big new features.
- 1.0: Yay, strings stable, bugs quashed, happy days.
- 1.X: Oops, someone found a bug. 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. I would only do a 2.0-UnstableX release if I am trying out a really radical change. But we are back to use-at-your-own-risk. The previous branch stays recommend until 2.0-RC1. This is the biggest change from my previous practice. Initially, I though I should only branch and bump the Major number for large changes that break the API. But really, there is nowhere else to put even small new feature adds that need testing.
Sounds exactly as intended
This sounds great, exactly as these things are intended to be used. I'd be happy if you put this post into a handbook page on d.o in the appropriate section about how to manage a project and releases. Thanks for the write-up. ;) -Derek (dww)
Glad you like it. I have
Glad you like it. I have changed the voice to third person and posted it at: http://drupal.org/node/396286.
The new open handbook system is most excellent.
Sounds good
I know that differs from what "alpha/beta" traditionally mean but that plan seems to work good in the Drupal environment. That's pretty close to what I do as well except I try to make each alpha/beta as bug free as possible so people can use them if they like. The catch with using them is that the next version may change radically and you need to be willing to take that risk. That's how I worked it with Advanced Forum and I had a couple thousand users while it was still in alpha. It was a bit bumpy if you wanted to customize your style but seemed to work pretty well as long as you stuck with the tested alphas/betas. Now that I'm in RC, I'm _very_ careful about what changes I make and new features, tempting though they are, get put on the 2.x list.
Michelle
Yeah, the danger is that
Yeah, the danger is that naive users end up installing Alpha modules without understanding the risks they are taking. And I was contributing to this by not cutting a new branch to add alpha features. So even though there was a perfectly stable 1.1 version, new users coming to my project page would see 1.2-alpha1 as the "Recommended" version. Looking at my usage stats, I see 60% on 1.1, 20% on 1.2-alpha1, and 10% evenly scattered over everything else. That 20% is too high.
I appreciate your approach of making even your alphas as solid as possible. On the other hand, it seems to be entirely acceptable for even big drupal modules to strand users during beta, making big changes without an upgrade path or an apology.