Johan Vromans wrote: > 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.
Nit - CPAN history has 0.50, 0.63, 0.64, 0.65, 0.651 and 0.652. Hardly 652 releases.
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.
I disagree. What you're seeing are the inevitable interactions of integrating two complex systems. Ideally, this would have been happening in some development branch behind the scenes. But since both are being tested in blead, you're seeing it live.
The "dancing" is the result of one bad call, one complex problem and one big bug along the way:
1) The Bad Call: version used Module::Build::Compat's "passthrough" mode, which is a bad idea in general and should never be used for any module that is or will become a Module::Build dependency.
2) The Complex Problem: Dual XS/PP modules are not hard to do (e.g. Params::Validate), but they do require robust compiler detection across platforms, which is why version was trying to use M::B only. Borrowing custom Makefile.PL code from Params::Validate addressed that problem. (P::V's compiler detection code was recently tightened up for Win32 thanks to Vanilla Perl)
3) The Big Bug: M::B relied on YAML::Node to behave as a hash, when it's a tied hash that doesn't have real hash semantics. $node->{value} can be true but exists $node->{value} can be false. Who knew? The documentation for it is wrong. M::B was written to serialize version objects if a version object existed -- but the "exist" test failed.
All three are specific, well-understood (in hindsight) and have now been addressed.
None of it suggests a major design problem, with the exception that this does remind us of the relative fragility of the M::B bootstrap/upgrade process.
The whole toolchain still depends on EU::MM being available to upgrade components that Module::Build depends on. Now I'll going into heretical territory myself and posit whether we should consider having M::B also rely on EU::MM for installation rather than having it try to bootstrap itself. I suspect that it would make upgrading M::B much easier and allow modules that depend on M::B to specify versions of M::B that they rely upon without self-upgrade problem that Adam Kennedy keeps pointing out.
Essentially, everything would be EU::MM until M::B is installed. Food for thought. Regards, David Golden
