Question

According to the Perl source code page on CPAN, 5.8.9 is now 14 days old, and will be the last 5.8 release. 5.10.0 is over a year old and presumably ready for use in Production.

Leaving aside discussion of Perl 6 for now, can I ask what versions of Perl folks are testing, rolling out and using in production? We have currently standardized on 5.8.8 on our Ubuntu (workstation) and Solaris (production) platforms, and I'm wondering about the pros and cons of making small step to 5.8.9 or a larger one to 5.10.0.

Was it helpful?

Solution

According to the Perl Survey, performed over a year ago now predating 5.10, as their minimum version of Perl people are using...

4.x     3%
5.0.x   3%
5.4.x   2%
5.5.x   6%
5.6.x   17%
5.8.x   66%

and the maximum is...

5.6.x   3%
5.8.x   88%
5.9.x   5%

5.6.1 and 5.8.8 are most popular within their major group. The missing percentages are miscellaneous versions.

Since the survey didn't define what "using" means, ie. if you're actually running production code on it or if you just test your software against it for backwards compatibility, or you just have it around for kicks, the minimum can be taken with a grain of salt.

This data, and the general lack of feedback from users, lead me to drop support for 5.5.x from the module installation toolchain modules I maintain (MakeMaker and Test::More) effectively end-of-lifing 5.5.x. 5.6 has had a stay of execution, but is still on death row.

I personally only recently switched from 5.8.8 to 5.10.0. I know of places still using 5.6.1 in legacy apps, but they've moved to 5.8.8 for as much as possible and all new dev. I don't know of anyone still using 5.5 in production. For backwards compatibility I test against 5.6.2, 5.8.8 and 5.10.0. The numbers say I should be testing 5.6.1 instead of 5.6.2 but there's only so far I can be arsed by folks who won't even upgrade to the latest bugfix release in their line.

OTHER TIPS

Perl 5.8.8 is (and will be until at least 5.10.1) our production environment. The performance regressions in 5.10.0 (regarding @_ assignment in sub's for example) make it impossible for us in production.

But we run our test suites with both 5.8.8 and 5.10.0 to prepare our move to 5.10.x in the future. I'm trying to have a system that will compile the bleadperl and run our test suites with that also...

I use Perl 5.10.0 in development and 5.8.8 in production and code is tested for compatibility. But I haven't seen so many internal Perl bugs than in Perl version 5.10.0 It's really terrible. I have reported three easily reproducible assert violations and core dumping ones and still cope with some strange hard to reproduce bugs which causes core dumps, memory leaks and so.

Primary development 5.10, QA and production 5.8.8 .

I use primarily Perl 5.10.0. I test backwards compatibility on 5.6.1 and 5.8.8. I do still have a Perl 5.5.3 which I occasionally use. (I still have the source for 5.4.4 - or 5.004_04 as it was then termed; it is not currently built and I can think of few reasons why I'd need to do so.)

Thanks for the information about 5.8.9. I'll have to get that.

I just started using 5.10.0 a few weeks ago, but I keep testing my modules on 5.8. When I upload something on CPAN I will put an effort in making it 5.6 compatible if possible.

We're using v5.6.1 in our production server. I guess we're old school. :P

Unless there's a specific features that you need, I think just upgrading might require plenty of testing on all related components.

So that only answers your first question. For the second one, you might want to research on what's the new features in the newer version.

You might also like my answer to How do YOU manage Perl modules on Linux?. I install several versions of Perl and test against many of them.

5.8.8 on FreeBSD for production and development. We're preparing to roll out a VM/jail to test 5.10 in (to verify compatibility for the future).

I use Perl 5.10, mainly because I can hardly wait until Perl6 implementations, are more complete

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top