Changes between Version 2 and Version 3 of HowToDeprecate

Timestamp:

06/28/10 08:19:02 (12 years ago)

Author:

cotto

Comment:

rough outline, needs fleshing out

HowToDeprecate

@@ -1 @@
-Document your change in source:trunk/PBC_COMPAT. More detail about which changes effect PBC are described in this file.
+So you've found a crufty bit of code in Parrot that's just screaming to be removed.  Welcome to the club.  There's a lot of them.  This page documents the proper procedure to go through to get that junk code out of Parrot while causing minimal pain to Parrot's users (i.e. people who develop HLLs or libraries on top of Parrot).
 
-When deleting a PMC, you change the Parrot bytecode format. This means that you must regenerate files in t/native_pbc/ with
-{{{
-sh tools/dev/mk_native_pbc
-}}}
-or you will see lots of failures in t/pmc/packfile*.t .
+=== Step 1: Give Notice ===
 
+ * file a ticket
+ * add a note to DEPRECATED.pod
+ * maybe post to parrot-dev and/or parrot-users depending on the nature of the change
+ * get some feedback indicating that the change is sane
+
+=== Step 2: Wait ===
+
+ * don't nuke anything until after the next supported release has been cut
+
+=== 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
+
+=== Step 4: Document ===
+
+ * 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
+
+=== Step 5: Apply ===
+ 
+ * merge or commit your changes to trunk
+ * close the deprecation ticket
+ * bump PBC_COMPAT and run mk_native_pbc if needed
+ * that's it