[parrot-tickets] [Parrot] #407: post-1.0 pbc reader policy

[Reini Urban]

chromatic schrieb:
> On Sunday 08 March 2009 18:07:04 Reini Urban wrote:
> 
>> 2009/3/8 chromatic <chromatic at wgz.org>:
> 
>>> Please read our support policy regarding bytecode changes and deprecation
>>> cycles.
>> pdd13_bytecode.pod:
> 
> Our support policy regarding bytecode changes and deprecation cycles is 
> instead docs/project/support_policy.pod.  In particular:
> 
> 	In future releases, we might make changes to the bytecode format that
> would prevent bytecode generated on one supported release from running
> on a later supported release. These changes will follow our usual
> deprecation guidelines, with adequate advance notice.
> 
>> In fact, once Parrot is in production use it will be
>> preferable to write as early a bytecode format as is possible, to allow the
>> greatest compatibility with previous Parrots.
> 
> That is contrary to our discussed and documented backwards compatibility 
> policy, as you can read in the document from which I previously quoted.


I'm sorry, I totally overreacted then here and in r37222 - trunk/src/ops.

But I miss more details in the "Bytecode Compatibility" section in 
respect to our current PBC_COMPAT and packfile.c policy.
opsrenumber reflects the current policy, but the PBC_COMPAT and 
packfile.c policy not.

Currently any change in PBC_COMPAT makes the pbc totally unportable 
within one deprecation cycle, but with the change in opsrenumber 
post-1.0 we at least try to be compatible with older pbc bytecode 
versions, so consider TT #407 to allow PBC_COMPAT changes *within* a 6 
months cycle. Otherwise we are not allowed to change any ops or pmc 
interface at all. That would be a bit harsh to forbid any change there.

The "bytecode format" section you cited talks about the pbc format, 
which has nothing to do with the bytecode versions which depends mainly 
on pmc or ops changes.

"In future releases, we might make changes to the bytecode format that
would prevent bytecode generated on one supported release from running
on a later supported release. These changes will follow our usual
deprecation guidelines, with adequate advance notice."

This prevents any ops and pmc changes, even adds, for half a year, which 
is clearly not what we want. Or do you want that?
-- 
Reini Urban
http://phpwiki.org/  http://murbreak.at/