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 <[EMAIL PROTECTED]>
