2009/3/9 <[email protected]>: > Author: allison > Date: Mon Mar 9 01:56:58 2009 > New Revision: 37222 > URL: https://trac.parrot.org/parrot/changeset/37222 > > Log: > [cage] Delete reference to ancient and long-abandoned bytecode policy, > to avoid confusing new contributors.
So since when are we in production? My understanding is that the first production release starts with 1.0 With this change we lost now cross-version bytecode portability and we will win the habit of randomly changing ops and pmc numbers as before. The pbc designers thought about that long and hard, and set a date when these random changes should stop and should be exchanged about a support policy which should help keeping backwards portability. With this change of yours we've finally lost all what the designers planned in the beginning. "ancient and long-abandoned" is not valid here. It was always considered that we will start a sane pmc and ops deprecation concept with the first "production release". Shouldn't we postpone the first production release then to eg. 2012 and tell the users that we are not ready yet, and that we still want to jungle the ops and pmc indices around? Note that all these policies only require documentation changes. Technically, getting cross-version again might be possible by adding the pbc and ops names additionally to the indices and if the BC version does not match, resolve the indices via the name. That was my idea to solve this problem. > @@ -1,6 +1,6 @@ > # This file provides opcode name->number mapping, so we can nail down > -# the op numbers for the core opcodes and provide > -# backward-compatibility for bytecode. > +# the op numbers for the core opcodes in a particular version of the > +# bytecode and provide backward-compatibility for bytecode. > # > # The format of this file is simple: > # > @@ -10,12 +10,6 @@ > # opcode--i.e. for the "add N1, N2, N3" op the name is add_n_n_n, not > # add. > # > -# once an opcode is added to this file it should never be > -# removed. Opcodes that are in here but that have no corresponding > -# function backing them (because, for example, they've been deleted, > -# which shouldn't ever happen once we hit production) should be mapped > -# by the ops processing programs to an exception op > -# > # The numbering of opcodes whose names are *not* in this file begins > # immediately after the highest-numbered opcode in this file, > # regardless of what order it is found in. There should be *no* holes -- Reini Urban http://phpwiki.org/ http://murbreak.at/ _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
