allow upgrading installed perls

[doy]

Since modern perl releases are binary-compatible within a major version, it would be nice to allow upgrading an existing perlbrew installation to a new version within the same major release. At the moment I tend to get stuck with 5.12.0, 5.14.0, etc because I upgrade for the major release, and then I'm too lazy to take the time to reinstall all of my modules for a minor release.

[dagolden]

I've been thinking that using a local::lib is the way to handle that, as long as perlbrew can associate any local::lib with any installed perl. So you would install a new minor perl, switch to it plus your local::lib and you've got all your modules ready to go.

(If the perl-apiversion-in-archname patch ever goes into Perl, that would even work across major version releases for any of the pure-perl modules.)

[gugod]

@hoelzro: Thanks for you time to implement it. I tried it, but I decide it more works are required before it is released. It is merged as a feature branch named "feature/upgrade-perl-in-place" in the repo.

IMHO, the command can be simply named upgrade, but it should take arguments for the installation that needs to be upgraded and a version to upgrade to, instead of assuming the latest version and upgrades all installations. For example:

perlbrew upgrade perl-5.14.1 --to perl-5.14.3

Also since "perl-5.14.1" is the default installation name with version number, it will look odd in the perlbrew list after it is upgraded:

perlbrew list
* perl-5.14.1 (5.14.3)

Also users would need to say perlbrew use perl-5.14.1 in order to switch to version 5.14.3, because the installation dir cannot be simply renamed to perl-5.14.3, everything breaks if you do that. There's a relocatable build flag that we could've utilized before for this purpose, but it is not at the moment. Maybe this flag should be enabled by default just to support the upgrade feature, but I'm not entirely sure it's sound to do so, we need to try.

As a result, if the upgrading perl installation is a named one (named with the --as arg in the install time), it looks good and make sense.

It also makes sense to let "5.14" means "the latest version of 5.14.x" so user can say perlbrew install perl-5.14 in the beginning and latter perlbrew upgrade perl-5.14. The installation is named "perl-5.14", but the actual version varies. This approach does not involve renaming the installation dir after upgrading, thus less flaws are expected, if any.

So this is actually a pretty big topic, but at least the upgrade command needs to take arguments before it it released :)

[hoelzro]

Yeah, I definitely didn't expect the code to be released anytime soon! It's pretty simple, and it definitely needs a lot of testing. Regarding the command line syntax, upgrade-perl only upgrades the current perl, not all. But I do see your point about upgrading to a given installation.

I understand your point about upgrading a perl named perl-5.14.1 to 5.14.3, however, I wouldn't expect people to do this. If I have a Perl called perl-5.14.1, I'm keeping it around to test things against 5.14.1. If I want to test things against the latest 5.14, I'd use a Perl environment called perl-5.14, and keep that one up-to-date. I think this is a compromise that users using the upgrade feature should understand. The compromise also happens to solve the relocatable issue.

[doherty]

I think perlbrew can do this now, no?

[erickpaquin]

@doy Is this PR still relevant? Been opened for over 12 years now. Time to close it?