Version 5 (modified by jkeenan, 4 years ago)

Add headline

How to Deprecate Parrot Code

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).

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

  • 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
  • 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

  • add a summary of your change to ParrotDeprecations
  • add a complete description to the appropriate version transition deprecations page (e.g. ParrotDeprecationsFor2.6)
  • 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

  • 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
  • that's it