Paul Marquess wrote on 2009-10-04:
>>> So the logic in Makefile.PL becomes something like this (completely
>>> untested)
>>>
>>> (
>>> $] >= 5.009 && $] <= 5.010001 && ! $ENV{PERL_CORE}
>>> ? (INSTALLPRIVLIB => '$(INSTALLARCHLIB)')
>>> : ()
>>> )
>> But what about people who have, say, 5.10.1 installed, and then
>> upgrade to 5.10.2 in the same installation directory? They should be
>> backwards-compatible, so that should work without having to start over
>> with a fresh perl installation, but if we switch to the logic above and
>> revert the corresponding core change to installperl and
>> win32/FindExt.pm to match then the 5.10.2 files will go into lib and
>> won't be seen because of existing 5.10.1 files already in archlib.
> Do people actually do that? Any time I ever upgrade, I start from
> scratch and wipe the old one.
Yes, I always start from scratch too, but I think people do upgrade existing installations in-place, and the ability to do so is one of the main concerns with backwards-compatibility of new maintenance releases.
>
>> I think you're right that it doesn't need to stay in archlib
>> long-term, but I think it has to stay where it is for 5.10.x.
> I'm happy to go along with that if in-place upgrades are likely to be a
> problem.
>
>> What happens with 5.11.x probably doesn't matter so much given that
>> they're development versions anyway, so maybe make the above $] >=
>> 5.009 && $] <= 5.011001 ? Then revert the two core changes to match,
Oops. I should have written $] >= 5.009 && $] <= 5.011000 there. It's 5.11.0 that's just been released with the installperl and win32/FindExt.pm changes in; they'll be gone by 5.11.1 if we stick to this plan.
>> and make sure that the original two core changes get merged into 5.10.x
>> (the installperl change is in already, but the win32/FindExt.pm change
>> isn't yet), and especially make sure that the change that reverts them
>> doesn't get merged into 5.10.x.
>
> Ok.
>
> Paul
Thread Previous
|
Thread Next