How do modules come up with their green, yellow, and red releases?

Question

As we all know, not every module marked "Recommended Release" on drupal.org is truly stable. In fact some modules are perpetually marked beta, in some sort of permanent limbo state. Even when hundreds of sites use them every day.

I was wondering what kind of standards or best practices do you use, as a maintainer or contributor, in your modules to mark releases 'Recommended' (Green), 'Other' (Yellow), or 'Dev'(Red)? What do you use when marking it beta, alpha, or stable as well?

Thank you in advance for any advice, help, or documentation you can provide.

NOTE: Many of these standards may be general standards for coding or project development. I simply wanted to know what methods or standards are used in Drupal modules specifically, even if they are / can be generalized.

Answer 1

Many of these standards may be general standards for coding or project development.

In Drupal there is no standard for this. It is left to the best intentions of the module owners.

My personal philosophy is:

• Release beta and/or releasecandidate if tested in a testing environment, or if all testcases pass.
• Release stable only if I, myself, have successfully implemented the (version of the) module in at least three different real-world projects; or if someone whom I know has my standards, did that and reports back.
• A module can be finished. It needs no additional work ever anymore. Something that is limited and scoped in featureset, is stable and predictable. Such modules need no bugfixes, feature-requests or tasks.

In practice, this means very few releases, yet the releases done will affect hardly anyone. That results in hardly ever releasing anything in practice.

My reasoning behind this is:

• People in issue-queues hardly test appropriately: they apply a feature, fix or patch, hit f5, see it working and say "yes, works for me +1". "It seems to work" is not equal to "it is fixed". You need trustworthy testing, or else the rest, those who did not even test the change, will flock in with issues reporting something COMPELETELY BORKEND, need fix NOW!!.
• Only when a module is implemented in different situations and environments will it have some real-world experience. Most often, during the second implementation you find that you need to rewrite some central api's, forgot some usefull parameter, or simply had a wrong idea about the need for some feature. Only after real-world deployment can something be considered stable. Else it is only stable in theory.
• Developers and maintainers of sites, the users of your modules, need to put a huge effort (far more then in any other piece of software I know) in keeping up with new releases, security releases and new versions. any relief for that effort (and budget and time) should be more then welcome.

Answer 2

If there is a module that you use where you found bugs the best thing you can do is file an issue. Even better is if someone writes a patch for that issue, the patch can be written by a developer that needs the feature or it can be written by a developer who got sponsored to write that patch. Contrib maintainers usually maintain a lot of modules and when you create a module you automatically become the maintainer, needless to say that puts a lot of strain into us, so we alway need help by people who write patches, sponsor patches or review them.

When you maintain releases in drupal.org you have a 'Supported' checkbox, enabling that will give you a recommended release (green) and if you also enable the 'Show snapshot release' you will get a dev release (red). If you have more then one major versions of your module (6.1 & 6.2) you can choose which one will be in the the recommended release section (green). Only betas and regular releases will go into the 'recommended' section (green) alphas and lower releases will be displayed in the 'other releases' section (yellow).

Answer 3

Regarding betas, rcs and dev, it depends on the popularity and niche your module fills imo.

If earl rolled out an official version of views that had a data loss issue the internet as a whole might cease to function.

However, if you have a small module that is relatively unpopular (>1,000 users) and youre just just going through routine bugfixes it is more reasonable to just make new releases and not beta/rc them.

if you know youve made some big chnages or seen alot of churn then test more thouroughly.

I tend to test and roll betas/rc when i am altering the DB or issuing update() hooks because i realize the permanence of data loss. I can reroll and rerelease a small bug fix fast right the world but i can recreate your sites data.

Hope that helps.