Forcing updates?
Today Perl 5.12.0 saw the light of the day. It includes some cool features. For example, to define package versions on the package keyword is great. But these new features (including in the same bag the new features from 5.10) make me discuss with myself about their use or not.
That is, I know several people that does not update their servers. They are in production for a long time, and they do not want to risk it all getting broken. This means they can't use recent module versions if they include new syntax improvements like the ones added in Perl 5.10 and 5.12. I, me, myself, have a similar problem. On my server I am running 5.10.0 with a bunch of small websites, and I am afraid of updating as well, as I do not have the time to go through all the sites and check they are running properly. Probably I should have a test suit to validate them. But I don't have. Also, probably I should have a list of the sites running, that I do not have as well.
But things can be seen in the other direction. If nobody uses these new features, they are useless. In that case, just the bug fixes would be relevant. Also, how would we convince users to update?
With this post I just want to make some people comment on their feelings about this. What both developers and system administrators do regarding this issue?...
That is, I know several people that does not update their servers. They are in production for a long time, and they do not want to risk it all getting broken. This means they can't use recent module versions if they include new syntax improvements like the ones added in Perl 5.10 and 5.12. I, me, myself, have a similar problem. On my server I am running 5.10.0 with a bunch of small websites, and I am afraid of updating as well, as I do not have the time to go through all the sites and check they are running properly. Probably I should have a test suit to validate them. But I don't have. Also, probably I should have a list of the sites running, that I do not have as well.
But things can be seen in the other direction. If nobody uses these new features, they are useless. In that case, just the bug fixes would be relevant. Also, how would we convince users to update?
With this post I just want to make some people comment on their feelings about this. What both developers and system administrators do regarding this issue?...
I blog about Perl. D'uh!
Upgrading Perl and vetting your applications on newer versions of Perl (and upgraded CPAN dependencies for that matter) doesn't have to be hard. However, you have to plan ahead a bit when writing applications in order to achieve this portability. Typically I never use the 'system' installed Perl for my applications, I will install an application Perl either in my user home directory (for when I am consulting and working alone) or into a globally accessible area for all my developers. This step helps disassociate your application development needs from how your OS is using and managing Perl; it also builds your competency in building and installing Perl.
Next we always write applications as though they are destined for CPAN, even if they are not. Using the CPAN toolchain, along with local::lib for granting user level dependencies, will really help you write portable applications that are easier to deploy and make it possible to keep closer to CPAN and Perl current.
This technique has become I believe the defacto best practice for writing Perl applications.
Unfortunately you probably don't have the luxury of a new application and that's the problem. Typically older Perl applications will be a mess of hacks trying to get around all the management and deployment problems the CPAN tool-chain solves more elegantly. Converting old applications can range in difficultly, getting the existing developers onboard with the approach will likely be harder. However the choice here is to stop using Perl and slowly you are are writing a private language that only works for one company. Down that road madness lies.
One major complication that often crops up is mod_perl. Although mod_perl based applications were for many years the lifeblood of Perl web application development, over the past few years new applications tend to prefer fast cgi (or more recently are building innovating stacks based on the Plack ecosystem) avoiding the complexity of mod_perl and the fact that you must compile a Perl version into Apache. That alone is a primary reason many companies are stuck on Perl 5.8 or older; nobody has time to rebuild Apache for newer Perls, and when it gets mentioned during planning capacity sessions you inevitable get one person who says, "Hey, we are still using Perl? I though we did away with all those systems years ago..." and then instead of talking about future Perl you are back on the defensive. This FUD and animosity is also a prime cause of Perl version stagnation.
For me, I am already running development builds of my new application on Perl 5.12.0 right now. I started the application on Perl 5.10.0 and we are running it also on our server farm, which is stuck on Perl 5.8.8 :( but, the key here is I feel confident my application is built to grow for the future, since I followed the path outlined above.
Writing for portability and growth definitely take more discipline. That's why its great to get involve in write CPAN modules and joining exising CPAN projects. Being in one of these communities is personally rewarding and it builds your competency in making good Perl applications.
Hi Alberto
I'm with John on all his points:
o Own Perl if possible.
o Own module dir. Hence local::lib and cpanm. This in turn means you can blow this dir away if a new Perl is not binary compatible. /And/ you can update any module knowing it affects noone else.
o All modules and all apps written as though destined for CPAN. Hence everything can be built into a distro, even if you don't actually do it.
o And yes, that means a minimal t/*.t suite, e.g. to ensure a module loads, and the POD's ok (however minimal). Just cut-and-paste from any other module.
o And yes, that means each (command line) *.pl using, for me, Getopt::Long and Pod::Usage, for standardized option handling and help output.
o And yes, it's requires a bit more discipline than just type-at-top-speed, but the rewards are less, much less, pain.
o It's important to acknowledge Apache and mod_perl's achievements, but these days it's no code tied to Apache (unless the customer orders it!), so that means Plack, Moose, CGI::Application, CGI::App::Dispatch, Try::Tiny, Capture::Tiny, Config::Tiny, etc. Each person has their preferences, of course. I don't expect John (or anyone) to agree exactly with my set of choices. The point is to standardize on a set of modules in the same way you've standardized on Perl, and the latest Perl if possible.
o If somebody attacks you for using Perl, I prefer a vigorous and oh-so-polite response, but that depends on how self-confident you are. Something along the lines of "You're sounding very old-fashioned and out-of-touch. Perl5 and Perl6 have moved on emormously of late".
o The whole point is to write reliable code, so you can turn your back on it, and it doesn't fall over. This is quite different from installing the latest 'X-thing' just because it's the latest.
Cheers
Ron