Reini Urban wrote:
I'm sorry, I totally overreacted then here and in r37222 - trunk/src/ops.
Forgiven.
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.
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.
Opcode and PMC numbering are part of the bytecode format, because
they're frozen within the bytecode. That is, a PBC file stored with a
different opcode and PMC numbering than the current interpreter will
require file translation just as much as a PBC file with a different
packfile structure. All of these kinds of changes (and more) are
required to add entries in PBC_COMPAT.
"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?
It just means we have to include a deprecation notice if we anticipate
changing the bytecode between two supported releases. The way the
deprecation cycle works, we can make changes with a deprecation notice
right after the supported release.
Thanks for the reminder, deprecation notice added in r37446.
> 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.
Once the pace of development settles, we will start supporting versions
of bytecode older than the current latest version. A bytecode migration
tool is on the roadmap for 2.0, and increased portability and packfile
format work is on the roadmap for 2.6. So, it will likely be 3.0 or
later before we adopt a feature similar to TT #407.
When we do adopt it, I expect it'll take a form something like "support
all versions within a major series", so bytecode versions 4.0 through
4.22 are all compatible, but 5.0 is not compatible with 4.0. But, we
have a couple years to think about it, and can decide what makes sense
for Parrot when we get there.
Allison
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
