By jasonwhat on
Currently there are several modules in CVS that are in one of three states: 1. 4.7/head compatible, 2. 4.6 modules that are in development and 3. old modules that have not been updated for awhile, which is why they only reside in CVS.
CVS modules should be further separated based on their compatibility, or at the very least, all modules should list their compatiblity on the teaser/overview page, some already do this. However, my vote is for further separating CVS by compatibility. Either way, there should be no need to download a module and read the readme.txt or worse, wait until the module is installed to discover if it's compatiblity. Maybe a good use for tags?
Comments
that's what branches are for
I hear you that for CVS HEAD users ... the waters are a bit murky , but HEAD is only intended really for developers, testers, early adopters, etc - and hence people that are probably helping to determine these states anyway.
Otherwise, as long as contributors are diligent about keeping things properly branched, stuff should work with the corresponding branch.
--
James Walker :: Bryght Guy
--
James Walker :: http://walkah.net/
All the more reason
I and many others would test more if we could more easily see what version the module is compatible with. I can't understand why there would be any opposition to this, and I can't imagine it is that hard to implement. Just some terms added to the "head" taxonomy related to the project module right?
This is another one of those, "Can't for the life of me understand why this isn't done," situations. As a non-developer it seems so obvious that this would be useful, just like putting all of a modules setting in one place, rather than having some under a module menu item, and some withing the "settings" menu item in the admin section of a drupal site.
You'll need to become
You'll need to become familier with cvs or versioning control systems so that you will understand.
If you wan't to know if a module will work, you have a couple of approaches. Try it. Look at cvs commit messages for that module to see what commits there are and when they were last committed. Contact the module contributor and ask.
If you want to test stuff, you need to get involved with the person writing it so your help can be effective. Perhaps there are plans you are unaware of. Perhaps there is a small group working on it already. Perhaps the contributor is busy and has no time. Perhaps the module is for 4.5 and not 4.6 becuase of additional functionality added in 4.6 renders it unecessary. Parhaps they are waiting for the next version to be released to even begin testing. Perhaps the contributor is no longer interested in it and is abandoning it....
All these are reasons I have seen for why modules arn't updated past the branched version and even if they are branched, there will still be a cvs version becuase the cvs version is the root code that the versions are branched from.
-sp
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
Okay...?
And why does any of this mean they can't tell us what is compatible with on the CVS page? If I'm browsing the growing list of modules, I should be able to quickly know if something exists, or is in the works that meet a particular need and what version it is compatible with. Why force someone to look into CVS messages or download and look at the readme just to see that the module hasn't been maintained since 4.3? It seems pretty common sense to me.
Please download the project
Please download the project module and take a look at what it's capabilities. As to what is placed on each page, that is up to the project maintainer. You will need to contact them to ask their reasons as my explanations are evidently insufficient for you.
-sp
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
right
From my playing around with it you just need to enable some subcategories for CVS. But if I can't convince you, I probably can't convince them. I'm curious what you think the negative effect would be of having extra CVS tabs with 4.3, 4.4, 4.5, etc. when viewing the project/Modules/cvs page.
I agree. Something like:
I agree. Something like:
And yes, it would be nice to have some information about each module. Something like an info section.
Most of this stuff is relatively easy to find. It would be nice to have it in one place for all packages. It would make it easier when pulling up content from a search as well.