as pointed out in http://drupal.org/comment/reply/90436/165543#comment-165543 "idiot-proofing" the new release system is a high priority. especially when it comes to the xcvs-* scripts that enforce the right tags and branches in the CVS repository, since that's the area where people have the most flexibility and are the most error-prone.

in addition to preventing users from deleting or moving cvs tags that already have release nodes pointing to them (http://drupal.org/node/90483), it'd be nice to enforce that the release tags for a given branch/release series must be added sequentially.

for example, if DRUPAL-4-7--0-1 exists, but not DRUPAL-4-7--0-2, we should prevent users from adding a DRUPAL-4-7--0-3 tag (or really, DRUPAL-4-7--0-N where N > 2). this is easy, since we have a {cvs_tags} table with all tags per project, and can easily find out the last real tag for any given release series...

in general, i think this will catch a lot of stupid errors, and it seems like something we'll definitely want to enforce.

(note: this behavior should definitely be controlled by a setting in xcvs-config.php (and probably off by default -- i'll have to look at how much special-case drupal.org code would be required for this, or if it can be done at all generically).

Comments

pwolanin’s picture

As per my follow-up in the forum, I think that enforcing sequential numbering would be unnecessarily restrictive, but that there should be a check that each new tag/version is greater than the previous. For example, if I want my module to go from version 1.0 to 1.5 to be suggestive of lots of bug fixes, etc.

dww’s picture

in a world where everyone was as comfortable with cvs as i am, i'd be more willing to allow this kind of freedom. however, i think that by forcing things to actually be sequential, what really clueful module maintainers loose in terms of flexibility, everyone else gains in terms of consistency and sanity.

plus, i kind of hate the notion that the version # would mysteriously jump from 1.0 to 1.5. i believe that will just confuse end users, more than it'll help be "suggestive of lots of bug fixes". if it's such a major change, make a new branch and new major version number (e.g. jump from 1.0 to 2.0 if you must). otherwise, just release 1.1 and the body of that release node will have a long list of bugs fixed, which will be more useful and meaningful to users of your module than a mysterious jump where 4 revisions are missing.

i dunno, i'm not 100% settled that it absolutely must be sequential, but i think the pros of this approach far outweigh the cons... that said, i'll give time for some others to comment here before i spend any time on this issue...

pwolanin’s picture

ok, you convinced me! At the least, I think keeping sequential more closely follows the KISS principle...

Let me know if there is an actual pieve of code I should look at.