Juergen Boemmels <[EMAIL PROTECTED]> wrote: > Dan Sugalski <[EMAIL PROTECTED]> writes:
>> We should keep the fingerprinting, since we can still have an issue where >> new bytecode can't run on old interpreters, but it's probably time to take >> another look at how we set the fingerprint. > If we want to keep the fingerprint it should be generated from the > ops.num file, Appending opcodes to ops.num doesn't break existing byte code. I'm thinking of this: We have a new file named COMPATIBLE or such, and do a MD5 sum over this file. Whenever we make an incompatible change that breaks existing byte code, the change is documented in that file, which automatically invalidates existing PBCs. > ... and it should be moved out of the header. Yes. I'm thinking of a Version PMC, living in the metadata. VTABLE_is_same() could check, if Parrot's and the PBCs version aren't conflicting. VTABLE_cmp() could compare if a loaded extension or module is compatible. The Version PMC could hold a STRING or an Array of STRINGs, that represent the version or version range(s). Proposals for such version checking are very welcome. > bye > boe leo
