context_pmc3 branch and backward compatibility.

[chromatic]

On Sunday 23 August 2009 19:34:56 Allison Randal wrote:

> > In context_pmc3 branch I converted direct using of Parrot_Context* to
> > Context PMC. Unfortunately it will break any HLL which depend on current
> > Parrot_Context struct.

> > So, question is "Does deprecation policy cover this situation and we
> > have to live with refcounted Context which causes memory leaks,
> > segfaults and eat kittens for breakfast until next deprecation cycle"?
>
> Yes, it means it has to wait. Which gives you plenty of time to add a
> deprecation notice, and think about a sane migration strategy for the
> users. And, to do performance testing, to see if the change will help or
> hurt us.

I think that takes backwards compatibility too far.

* We've never advertised the contents or layout of Parrot_Context as visible 
(or even documented) outside of the core.

* We categorically refuse to support functions not marked as exported and API 
functions; why support anything other than opaque data structures?

* We've changed struct layouts (and even existences) without deprecation 
notices before.

* If this becomes part of the policy, we can't merge most of the outstanding 
branches (pluggable_runcores and anything PCC rewiring especially) and we'll 
have to unmerge several branches (UnionVal removal and the fixed-size and lazy 
GC allocators) until 2.0.  I'm not sure that's feasable.

I'm sympathetic to languages which will need changes, but they're taking big 
risks by poking into the guts of Parrot itself we've never documented as 
available for external projects.  We don't even have an API for messing with 
these internals -- delaying the availability of such an API for another five 
months will only increase the pain.

Alternately, we *could* release 1.4.1 which contains deprecation notices for 
all of these changes.  I'm not sure I'm kidding about that.

-- c