Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.As per a recent message on the devel list, it's possible that the D6 version of cvs_deploy.module could be smart enough to figure out the right core compatibility based on the CVS tag and update_status release history data, and fill that in for use by the admin/build/modules page for folks deploying from CVS. If that's the case, we can tell maintainers they don't need to commit "core = 6.x" into CVS. It'd be nice to avoid that, since it will undoubtably lead to confusion and will get stale in some projects if people try to handle it manually.
Marking this critical, since getting this working will most likely require some changes to how admin/build/modules works, possibly by introducing a hook_alter_info().
Comments
Comment #1
dwwWell, the good news is that we have hook_system_info_alter() in D6. ;) The bad news is that I never worked on this and a bunch of contribs are already being tagged and released with this core=6.x in their .info files in CVS.
Comment #2
webchickI actually think this is fine. The core = 6.x line *requires* maintainers to change *something* in their modules between Drupal versions. And yes, it requires manual intervention, but so does updating your module anyway. And it's also a clearly visible indication to end users (or scripts that want to gather statistics on HEAD modules that are 6.x compliant) that the module is, in fact, for the right version of Drupal.
So I'd recommend setting this "won't fix" which would coincidentally also clean out your queue entirely. :D
Comment #3
dwwSure, sounds good to me. ;)