Yes, there is a need for more documentation volunteers and reducing the cvs barrier to entry for developers, even more for themers. In this case branching isn't necessarily the issue - the maintainer can simply edit the HEAD release node and designate it as compatible with Drupal 4.7. It will then appear in the list of 4.7 modules on drupal.org. Maintainers are also encouraged to designate the HEAD release as 5.x compatible in cases where it is working fine in d5 but they don't feel comfortable branching yet. If you make an issue for the appropriate project explaining this they will usually do so. Proper branching is nice and all, but the bigger problem is that there aren't enough module maintainers, or hours devoted to module maintenance, in general. The version-module support matrix feature request (http://drupal.org/node/63491) might help too. .ck Boris Mann wrote:
On 1/2/07, Chris Johnson <cxjohnson@gmail.com> wrote:
This is a pet peeve. Be forewarned. :-)
Today, for the Nth time, I again wasted time looking for a module in the 4.7 branch of the contrib repository that was not there. Why? Because it was in the HEAD branch, even though it only works with 4.7 -- and not 5.0 or later.
So this brings me to my pet peeve of the moment: module maintainers who do not branch their modules when appropriate.
How can this be made easier for people
We need a good concise document explaining step by step how to version code. Ideally with some popular GUI client examples.
and more reliable for folks who want to download or checkout contrib code?
Create an issue requesting it.
This will be an iterative process. This is the "next step" of having more professional "best practices" code management. Unfortunately, doing the actually branching can only be done by the maintainer.