On Fri, Aug 22, 2008 at 7:20 PM, Will Coleda <[EMAIL PROTECTED]> wrote: > On Sat, Aug 16, 2008 at 11:39 PM, James Keenan via RT >> 4. Parrot::OpsRenumber::renum_op_map_file() has been revised so that it >> will behave properly before Parrot 1.0 -- when deletion of opcodes is >> still permitted -- and after 1.0 -- when no deletions are permitted. >> This flexibility is attained by providing it with the Parrot major >> version as an argument. This before-and-after functionality is tested >> in a heavily revised t/tools/ops2pm/05-renum_op_map_file.t. Several new >> sample files used in testing have been added to the distribution. > > I know you were implementing Jerry's requirement here, and that's good. > > I do wonder what the plan is for opcodes that are marked deprecated > (which we can do today.) ; once they go past deprecated (before 1.0, > we'd just delete them), what will happen when they are executed? will > we add a :removed pragma on the opcode definition that will simply > throw an exception when they are invoked? Will we just silently > translate them to a noop? > > What about the case when we experimentally add an opcode between > official releases, but back it out before the next release? What > counts as an official release? How are we going to number the > intervening releases? Do we have a version indicator to mark as > stable/unstable/experimental/Don't Touch This Without A Hazmat Suit? > > What about experimental.ops? is that going to survive with its special > treatment into post-1.0? > > I apologize for not asking these questions immediately following > Jerry's original post, but I thought I had until version 0.99 to think > about it. =-) > > These questions asked... I'm don't think they block application of the > patch at all; I think these are all questions that should be answered > in a new docs/project/release_strategy.pod which can then spawn TODOs > as necessary. > agreed. we still have time to address these questions. it would be nice if they weren't lost, though. i suggest a wiki page rather than a mess of rt tickets for better tracking at this point. seems to me that the wiki approach will allow us to collect and organize these thoughts as they occur, and serve as a solid draft when we formalize them later.
>> 5. The name of the program that invokes Parrot::OpsRenumber is changed >> from tools/dev/ops_renum.mak to tools/dev/opsrenumber.pl. It is, after >> all, a Perl 5 program, so we provide it with a file name extension >> consistent with other programs in tools/dev/. >> >> 6. A new makefile target, renumberops, invokes tools/dev/opsrenumber.pl. >> >> Please review, particularly lib/Parrot/OpsRenumber.pm and >> t/tools/ops2pm/05-renum_op_map_file.t, which is where most of the really >> new stuff is found and/or demonstrated. > > I don't have any questions regarding these tests that are unique to > these particular tests. > it strikes me that the makefile target and the script name should be the same. there's still too much irregularity in parrot's naming conventions across the board--opcodes, pir syntax, makefiles, scripts, directories, filenames, c functions, etc. we'll concentrate on this in earnest as we approach our first general availability release (whether we call that release 1.0 or 2009R1 or "Ball of Mud"), however there's no reason to hold off. if anybody sees anything that looks a bit out of place (e.g. dynops vs. dynoplibs) take note of it by opening a CAGE ticket in rt. it may take some project team input to settle upon the preferred naming convention, but implementing that work can be done by any contributor and applied by any committer. ~jerry
