Re^3: Controlled CPAN breakage

It would be so much more convenient if the auto tools like cpanp and cpanm would take module versions into consideration and didn't jump from 1.x to 2.0 for example, instead following the current 1.x branch until the user makes a conscientious decision to upgrade.

Well, hah :)

See https://metacpan.org/pod/CPAN::Meta::Spec#prereqs for the bare-bone-ness

See Task for advanced bones

All you need, to get cpan/cpanm not to jump from 1.x to 2.x is add checks in all the related Makefile.PL equivalents, that does die "ABORTING; WILL NOT FORCE UPGRADE TO 2X VERSION WITHOUT Task::Foo2X\n" if not require Task::Foo2x;

Then Task::Foo2x does explicitly install DWALIN/Foo-2.0.1.tar.gz and all the stuff

Then you get everything you want, but naturally you have to update the 1.x version to have this enhanced Makefile.PL equivalents

Comment on Re^3: Controlled CPAN breakage Select or Download Code

Replies are listed 'Best First'.
Re^4: Controlled CPAN breakage by dwalin (Monk) on Feb 07, 2014 at 06:59 UTC
Not sure I understand what you're saying here. What exactly Task has to do with this problem? I'm not trying to bundle the whole suite of modules in one distribution, I'm trying to find an easy way to prevent the modules dependent on Foo from upgrading it. Say, I publish Foo::Bar that depends on Foo 2.0; that will make cpanm install Foo 2.0 automagically whenever Foo::Bar itself is updated - just because cpanm will fetch the greatest version of Foo::Bar available without regard to the major versions. If you're suggesting to use Task::Foo2x as a marker of sorts, then it can be done with an empty module instead. I think. Also I'm not sure that the approach you're advocating will bode well with the CPAN testers. I really appreciate the reports and don't want to lose them; dying in Makefile.PL would most probably break the toolchain and require manual intervention. Which I really doubt anybody would do. Regards, Alex.	[reply]
Re^5: Controlled CPAN breakage by Anonymous Monk on Feb 07, 2014 at 07:56 UTC
... blah ... Well, then there is no solution	[reply]