Voting starts in March for the Drupal Association Board election.
This is an offshoot of Re-number (core) updates according to major version (of Drupal).
We encourage module maintainers to join forces with others, but the code of many contrib modules is in an out-dated state. So the rule to continuously count module updates beginning from 1 turns upgrading and co-maintaining of contrib modules into a pain.
Changing the numbering scheme for contrib modules allows new co-maintainers of a module to learn which updates were needed in the past and more importantly, for which version. You don't know that by looking at e.g.
Like the new numbering scheme for Drupal core updates, the numbering scheme for contrib modules should be changed to:
512# |||| |||└ Continuous counter, i.e. starting from '0'. ||└ Minor version number of this module, i.e. '2' for module version '1.2'. |└ Major version number of this module, i.e. '1' for module version '1.2'. └ Major version number of Drupal this module's release is compatible with.
IMHO a contrib module won't need more than 10 database updates within a minor version. However, if we want to allow more, we certainly can append another # and start counting from '01'.
- module_update_4110 would indicate the first database update for version 1.1 that is compatible with Drupal 4.x.
- module_update_5172 would indicate the third database update for version 1.7 that is compatible with Drupal 5.x.
After there is an agreement on a new numbering scheme for contrib modules updates, the documentation (http://api.drupal.org/api/5/function/hook_update_N) has to be updated accordingly.