Index: install.php
===================================================================
RCS file: /cvs/drupal-contrib/contributions/docs/developer/hooks/install.php,v
retrieving revision 1.7
diff -u -r1.7 install.php
--- install.php	11 Jan 2007 18:09:15 -0000	1.7
+++ install.php	7 May 2007 10:50:20 -0000
@@ -151,11 +151,26 @@
  * Perform a single update. For each patch which requires a database change add
  * a new hook_update_N() which will be called by update.php.
  *
- * The database updates are numbered sequentially starting with 1 in each
- * module. The first is mymodule_update_1().
+ * Database updates consist of 3 parts:
+ * - 1 digit for Drupal core compatibility
+ * - 1 digit for your module's major release version (e.g. is this the 5.x-1.* (1) or 5.x-2.* (2) series of your module?)
+ * - 2 digits for sequential counting starting with 00
+ * 
+ * The 2nd digit should be 0 for initial porting of your module to a new Drupal
+ * core API.
+ * 
+ * Examples:
+ * - mymodule_update_5200()
+ *   - This is the first update to get the database ready to run mymodule 5.x-2.*.
+ * - mymodule_update_6000()
+ *   - This is the required update for mymodule to run with Drupal core API 6.x.
+ * - mymodule_update_6100()
+ *   - This is the first update to get the database ready to run mymodule 6.x-1.*.
+ * - mymodule_update_6200()
+ *   - This is the first update to get the database ready to run mymodule 6.x-2.*. Users can directly update from 5.x-2.* to 6.x-2.* and they get all 60XX and 62XX updates, but not 61XX.
  *
  * A good rule of thumb is to remove updates older than two major releases of
- * Drupal. Never renumber update functions.
+ * Drupal. <strong>Never renumber existing update functions.</strong>
  *
  * Whenever possible implement both PostgreSQL and MySQL at the same time. If
  * PostgreSQL updates are added later, add a new update function which only does