Changes between Version 3 and Version 4 of HowToDeprecate

Timestamp:

06/29/10 16:43:50 (12 years ago)

Author:

cotto

Comment:

--

HowToDeprecate

@@ -10 +10 @@
 === Step 2: Wait ===
 
- * don't nuke anything until after the next supported release has been cut
+ * pick an eligible release for the deprecation policy
+ * backwards-incompatible changes can't happen until a stable release has gone out the door with a notification of the coming deprecation
+ * see [browser:trunk/docs/project/support_policy.pod docs/project/support_policy.pod] for more information
 
 === Step 3: Patch ===
 
  * write the code, possibly in a branch
- * if possible, maintain backwards-compatibility to ease the migration
- * test your changes with HLLs and libraries such as partcl-nqp, Rakudo, winxed, Kakapo, etc
+ * unless it's highly impractical, maintain backwards-compatibility to ease the migration
+   - this also means you can commit your changes immediately and remove the deprecated interface later
+ * test your changes with current HLLs and libraries such as partcl-nqp, Rakudo, winxed, Kakapo, etc
 
 === Step 4: Document ===
@@ -22 +25 @@
  * add a summary of your change to ParrotDeprecations
  * add a complete description to the appropriate version transition deprecations page (e.g. [wiki:ParrotDeprecationsFor2.6 ParrotDeprecationsFor2.6])
- * walk through the the documentation to ensure that it's complete enough for a user to use to upgrade code
+ * walk through the the documentation to ensure that it's sufficient for a user to use to upgrade his or her code
 
 === Step 5: Apply ===
  
- * merge or commit your changes to trunk
+ * make sure the HLLs and libraries are ready the deprecation (and submit patches if not)
+ * merge or commit your backwards-incompatible changes to trunk
  * close the deprecation ticket
  * bump PBC_COMPAT and run mk_native_pbc if needed