Drupal Version

Problem Summary

Currently on Drupal.org, we recommend the very latest release version of Drupal core as the recommended download. But, it often takes Contrib and Docs much longer to catch up to the point where the system is stable and easy to use from an end user (site builder) perspective. Novice or less skilled site bulders who do not realize this and arrive "too early" get extremely frustrated as a result. Contrib developers are placed under extreme stress to have their modules ported as soon as possible, often long before they are ready to do so and with issue queues clogged by angry demands from frustrated users (instead of useful issue reports by more advanced users). Often by the time many users are able to work with the new release to build and upgrade sites, we are halfway through the next major release cycle. This makes it hugely expensive or impossible for many organizations to keep up. Finally, fixing bugs in the new release is very painful due to the necessity to freeze API changes and have strict backporting rules.

This problem causes a great deal of pain and conflict community-wide.

Proposed Solution Summary

This solution is based loosely on the very successful Debian Linux model. Please see the (brief) introduction to this approach at http://wiki.debian.org/DebianReleases#Introduction if you are not familiar with Debian stable/testing/unstable .

To implement this kind of "testing" release for Drupal would be laregly semantics and rethinking how we refer to releases on drupal.org. It would not require extra work or compromise from anybody, nor changes to existing workflow or versioning. In fact, it improves life and reduces stress for contributors.