I recently upgraded my version of client-side 64-bit ActivePerl from version 5.10.1.1007 to 5.22.2.2203, and am having tons of problems with it.
I'd really rather jump to Strawberry, but I'll have to test it first on each of the critical Perl apps I run on a daily basis.
Can I install the portable version of Strawberry and test it out while continuing to use the ActivePerl version for production work?
(Other stackoverflow questions similar to mine received answers about server-side Perl only.)
On
One of the benefits of berrybrew is that it allows you to install and use any of the Strawberry Portable editions in a managed way, with the ability to very easily switch back to your system perl (in your case ActiveState) at any time.
You can install from Github (above link), or via a zip file per the Installation instructions.
Then:
cd berrybrew
bin\berrybrew.exe config
Close cmd window, open a new one.
berrybrew install 5.24.1_64
berrybrew switch 5.24.1_64
Open new cmd window
At this point you're using Strawberry Portable version 5.24.1. To switch back to ActiveState:
berrybrew off
To go back to a berrybrew managed Strawberry instance, just use the switch command per above.
You can, you just have to watch which perl you're using. Only one can be "first" in your PATH. For this, I'd suggest leaving the old perl as the default, primary one. This will have the least effect on existing (production) code.
You can, however, have a secondary perl in your PATH with a different name. For example, perl5.22.2.exe could be in your PATH, and you can use it when running your tests.
If you have a batch file or similar as a wrapper around perl scripts, you can have the batch file for each app run the correct perl for that application, and you merely need a) a way to override the perl it uses, and b) to have it default to the tested level of perl you want it to use. That way you can test with 5.22.2 for a while, but the default remains 5.10.1. And then you can switch the default over to 5.22.2 when you're ready for that application to switch.
Whether it's client-side or server-side doesn't make any real difference to this.
(And platform doesn't make much difference, either - while the actual implementation on a unix/linux system might be a bit different, the general idea doesn't have to be. You can have both installed at the same time, and manage which perl to use on an application by application basis if you have to.)