How do modules come up with their green, yellow, and red releases? 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.
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.