For API changes, please update consumers when necessary

[Chip Salzenberg]

A question recently arose (about extend.c) about when it's OK to
change a public API, or remove it as obsolete.

Mostly I want to avoid surprise breakages. Not that I can eliminate
them. (I suspect I'll be responsible for a good number of them. New
lexical subsystem, anyone?) But for smaller things, let's try to keep
to the rule of "You break it, you fix it":

* If you change an API, it's up to you to make sure that consumers of
that API in the Parrot subversion tree are updated. You can get
the owner of the consuming code to do it, or you can get someone to
volunteer to help you, or you can do it yourself, but if there's any
question, the job is yours.

So out-of-tree projects must keep up with API changes independently.
Think of this as an incentive to have your favorite language in the
Parrot tree. :-)
--
Chip Salzenberg <ch...@pobox.com>