From: Steve Hay [mailto:SteveHay@planit.com]
> 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.
OK.
> >
> >> 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.
I guess the danger with adding
$] >= 5.009 && $] <= 5.011000
right now is, as you've already said, making sure we do something different
in 5.12. Might be safer leaving it to >= 5.009 only for now.
Paul
Thread Previous
|
Thread Next