Version 3 (modified by cotto, 12 years ago)

rough outline, needs fleshing out

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

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