Ron Savage wrote: >> I don't know all the inner details, but this M::B and version >> dancing gives me the strong impression that something is terribly >> wrong here at a fundamental design level. > > Clearly something's wrong, but it may not be anything big, even though it's a > sort of show-stopper.
The problem is one of communication and insufficient testing, not architectural. I didn't think to test on a machine that didn't have *either* M::B or version.pm installed (which is the only case where there is any problem). Additionally, I was busy with real life and I didn't notice that Ken released a non-alpha release on a Friday (not placing blame, just noting the facts). >> Dealing with version numbers is not quite trivial, but should be >> fairly straightforward to deal with. I cannot (and for the time >> being I refuse to) believe that it takes 651 releases (652 at the >> time I write this) to get it right. It hasn't taken that many releases; I'm using the additional digit to distinguish that the last three releases have included no code change, only Makefile.PL tweaking. > > Exactly. Ship a pure-Perl version immediately and stuff around with an XS > version off-line, so to speak. Pleeeeeeeeeeeeeeeeeeeaaaaaaaaaaassse! What you are both unaware of is that the XS code is the reference implementation, and is exactly the same code as appears in Perl v5.10.0 and has been basically stable for 8 months (some minor edge cases notwithstanding). The pure Perl implementation is newer, but no less stable. The problem is one of integration. I started using Module::Build for version.pm itself more than a year ago, because it made handling both XS and Perl code much more naturally. It didn't occur to me that on a virgin machine, version depends on M::B which depends on version, hence a problem. I gave Ken the choice of embedding a cut-down version.pm in the Module::Build stack, and rightly so, he declined because of the coordination issue (whether it was put into /inc or /lib) of having someone else's code, with a different release cycle, inside his distribution. He may reevaluate that now; I am fully prepared to maintain a parallel code inside M::B (since the code is already modular enough to support that). John -- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4501 Forbes Blvd Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5747
