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

chromatic chromatic at wgz.org
Sun Mar 15 20:56:17 UTC 2009


On Sunday 15 March 2009 09:48:21 Reini Urban wrote:

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

I think that has everything to do with bytecode versions.

> "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?

If merely checking version numbers of PBC and dying if the numbers don't match 
doesn't accomplish this goal, then checking version numbers of PBC is *wrong* 
and needs fixing.

As long as Parrot 1.1 through Parrot 1.3 can read and run PBC files generated 
by Parrot 1.0, I think we've satisfied the intent of the policy.  Ideally we 
can provide a migration tool for PBC generated by Parrot 1.0 to the PBC 
supported by Parrot 1.4, but I'm not sure we'll have such a tool by July.

This means, at the minimum, we can't renumber ops nor PMCs until right before 
a deprecation point.

-- c


More information about the parrot-dev mailing list