On Fri, Feb 17, 2006 at 02:01:30PM +0000, Nicholas Clark wrote: > On Thu, Feb 16, 2006 at 07:26:47PM -0800, Yitzchak Scott-Thoennes wrote: > > On Thu, Feb 16, 2006 at 02:07:50PM +0100, Rafael Garcia-Suarez wrote: > > > > On the other hand, if we begin to ship M::B with stable perls, a lot > > > of people will keep perl's M::B and not upgrade it. So we'd better be > > > sure it's pretty stable in terms of functionality and API. So I agree > > > with you here. > > > > Um. Those same people aren't likely to install M::B in the first place. > > I don't see how providing them with it (even if it will fall out of date) > > hurts. > > It won't hurt them, but it will cause immense pain for anyone wanting to > ship a module that uses a Build.PL - those developers will be forced to > decide whether to cut out anyone with an old Module::Build, or code their > Build.PL to use that version and work around the deficiencies.
I don't see the mountain, just a molehill. But maybe that's just me. For (wild speculation in absense of data) 99% of modules, Module::Build is feature-complete. The remaining 1% of modules (e.g. Tk) won't be switching to it any time soon, and when they do, they'll require version 0.30 or the like. > The thread on what YAML version Module::Build needs, and how to upgrade > correctly if there isn't >=0.50 suggests that solving these "Module::Build > needs upgrading" issues isn't yet battle tested. I missed that thread. What was the subject? Module::Build doesn't need YAML at all (though authors really should have it to generate a fleshed-out META.yml). And the current development version should work fine with current versions of YAML. I don't think anybody is suggesting putting 0.2611 in the core, and I for one wouldn't mind seeing the battle-testing that would result from putting 0.27_* in the core happen before 0.28 is released. > This is fine for 5.9 (anyone using 5.9 should be expecting surprises, > including unannounced binary compatibility breakages across any patch) > but not for stable, be it 5.8.x or 5.10.1. > There is time before 5.10 to solve this. [But hopefully not loads of time :-)] > > With respect to stability, I hope functionality continues to increase, > > and that backwards-incompatible changes will be severely limited. I > > don't see how this is different from any other module already in the > > core. > > > > However, I hope you are only applying this reasoning to 5.8.x. My > > That's why it's not suitable for "stable" now, independent of any policy > on assimilation. Disagreeing with the premise (assuming I've correctly identified your "That"), I disagree with your conclusion too. Oh well.
