I think we've got some semblance of a plan forming. Now we just need to
get all of the players involved and do it, right?
Approximately:
1. CPAN(PLUS) needs-upgrade self-awareness
2. configure_requires in META.yml
(and support in M::B, M::I, CPAN(PLUS))
3. create_makefile_pl => 'obsoleted'
# from Adam Kennedy on Wednesday 23 May 2007 04:27 am:
>Eric Wilhelm wrote: >>So, wouldn't the answer be "upgrade CPAN"?
>However, it's only a reasonable answer if it's a one-off action, which
>currently it is not.
Exactly. We just need CPAN(PLUS) to know they need to upgrade. After
the day those are published and mirrored, it is a one-off action.
>The second half of the upgrade work is to allow the CPAN repository to
>communicate to the CPAN client (by a mechanism that's basically "a
> file" but is still not fully defined) that it is incompatibly out of
> date.
I think that's the primary requisite bit for CPAN(PLUS). The clients
need to upgrade themselves.
We can't exactly configure_requires CPAN+CPANPLUS for Module::Build
(well, we can, but a "you must install both" could be somewhat
annoying.)
As for the mechanism, wouldn't a "major version bump" be sufficient
notice to cause CPAN(PLUS) to upgrade? The mechanics for distributing
that information are already there.
>> So, given all of that, my preferred compatibility Makefile.PL is
>> like:
>>...
>Some suitably blessed and battle-ready variant of that snippit would
>probably be the best solution for educating the user about the need to
>upgrade.
>...
>PLEASE don't start doing this until configure_requires is added to
>META.yaml (and can we please do this someone, I think everyone is
> happy at this point) and implemented in both CPAN clients.
Yes.
Thanks,
Eric
--
"Politics is not a bad profession. If you succeed there are many
rewards, if you disgrace yourself you can always write a book."
--Ronald Reagan
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------
