Home > Main > Upgrading and deprecating

Upgrading and deprecating

Sad things are happening in the Perl world. Sebastian Riedel has deprecated Perl 5.8.x support in Mojolicious without even saying why this was necessary. Despite admiring Sebastian for all the work he does and also his artistic capabilities on alternative Perl logos, I despise this step as extremely ill-advised and damaging to the whole Perl community.

In general, every software used by anyone else needs deprecation policies. If you throw a feature away, you have to announce it and make everything in your power to ease the migration pain for your users. A lot of sensible software employs a two-major-versions deprecation policy: if you deprecate some functionality in major version X, you add a warning and a migration recommendation in major version X+1 and remove the feature completely in major release X+2.

As opposed to other languages, Perl the language and Perl the community has been extremely backwards-compatible for a long time now. Quote chromatic from “Modern Perl”:

Perl 5’s design process in 1993 and 1994 tried to anticipate new
directions for the language, but it’s impossible to predict the
future. Perl 5 added many great new features, but it also kept
compatibility with the previous seven years of Perl 1 through Perl
4. Sixteen years later, the best way to write clean, maintainable,
powerful, and succinct Perl 5 code is very different from Perl
5.000. The default behaviors sometimes get in the way;
fortunately, better behaviors are available.

Anyone remember the Date::Manip disaster? I do and it has been an extremely bad move. It’s all the same for Mojolicious: it’s the fate of the libraries to support the lowest common determinator of all available platforms and a web framework is just such a library. The only question is: what do we consider an “available platform”?

The obvious reply is: take current distributions and look at the available options. That includes Linux distributions, both desktop and enterprise, Windows and a whole lot of other operating systems and hardware platform on which Perl can run. We’d probably arrive at 5.8 and 5.10 sharing the lead and 5.6 and 5.12 somewhat in the backseat.

A lot of Perl code runs in closed corporate environments and thus has to obey some rules, like using special software distributions, so unsurpisingly, a big chunk of those 5.8ers are enterprise Linux distributions like RHEL or SLES. However, just like Hacker News, where seemingly everyone assumes you are a start-up founder and thus free to go with all the current bells and whistles, Perl community started actively ignoring those distributions, proposing to “just upgrade your Perl / install perlbrew” when confronted with a problem instead of handling it in a sensible way. This is obviously wrong, since each developer is in a different situation.

My previous Perl project has been in a medium-sized department at a big electronics and IT company. It consisted of big chunks of legacy Perl code deployed as part of bigger internal website on RHEL5 servers. Developers had their freedoms, as long as certain constraints were fullfilled like not breaking the code of others (e.g. the big framework that was been wrapped around our code) and deploying with RPM packages. Thus, we could happily innovate and so I introduced Moose and many other modern Perl modules which have helped to clean that mess up.

Now, fast forward to today. Even then, I would have been happy to introduce at least some kind of web framework instead of the CGI-based mess we had then. Catalyst has obviously been on my plate for some time and today I would probably have considered Mojolicious for the task. However: being able to run it on Perl 5.8.x would have been a MUST, not a CAN feature.

Now consider this: companies buy enterprise products to get support. RedHat in provides seven years of support. RHEL3 (Perl 5.8) has been supported until October 31st 2010. RHEL4 (Perl 5.8) will be supported until February 29th 2012. End of March 2014 is when RHEL5 (Perl 5.8) will be officially dead. By comparison: Windows XP, first out in 2001 will be supported until April 2014. RHEL6 (Perl 5.10) will be supported until 2017. Which version of Perl will Mojolicious support then? Considering yearly Perl releases, probably only 2.20 upwards, since 2.24 will be current then.

So are the “evil big corporations” at fault here? Not at all. Perl 5.8 has been released in 2002 and as you see, RHEL3, released a year later, has catched up and delivered 5.8. RHEL4 and RHEL5 have seen minor Perl updates, since no major updates for Perl came out in that time. Perl 5.10 appeared half a year after RHEL5 released, so it hasn’t been included, Perl 5.12 has appeared roundabout at the same time as RHEL6 beta, so only 5.10 could have been shipped. So why does the community bitch so much about enterprise distributions if Perl itself doesn’t release often enough to get current software into them?

We, the programmers, always say “Don’t change a running system”. In that project I worked in, nobody in their right mind would have allowed me to uprade RHEL5 to 6 even if it has been available at the time. Even RHEL5 has been rather fresh, many of the servers still ran RHEL4 or even RHEL3. Nobody in their right mind would have allowed perlbrew on production servers. Nobody in their right mind would allow me to allocate hours and days of developers’ and testers’ time to retest everything with the newest Perl version (you don’t seriously assume legacy code had any amount of reasonable regression tests?)

The corporate world, which either still is or has been extremely Perl-friendly in the past, often needs to have some kind of long-term strategy, which for many has been Perl for years or even decades. Instead of supporting and cherishing that valuable connection, parts of Perl community has just decided to say a big “fuck you!” to all of those who try to create great software in restricted environments, those who try to persuade their bosses not to move to Java or .NET, because Perl makes them much more productive, to all those people who have considered using Mojolicious, to all of those who actually have. And all of those who complain get ignored, while uttering something about moving more stuff to 5.10 just to piss off all of 5.8 users.

Perl as a language is dependant on those walled gardens. Perl as a community is perfectly capable of taking care for those stuck with an older version. But obviously some people couldn’t care less and think that everything runs with HTML5 on websockets in the cloud nowadays and that everyone can and will upgrade whenever a fresh version of whatever software comes out.

It just doesn’t work this way. And it’s sad that some people in the community think it could.

christian louboutin sale,ralph lauren sale,louis vuitton bags outlet,cheap michael kors handbags sale,cheap wedding dresses online

  1. Matthew Musgrove
    May 8th, 2011 at 16:35 | #1

    To paraphrase you: “I want modern Perl features on my ancient servers.”

    My response: Tough. If you can’t run a modern Perl, then you shouldn’t expect modern Perl features.

    You can’t make every CPAN developer stick to a specific antiquated version of Perl just because you can’t upgrade. Each CPAN developer is free to pick and choose what Perl versions they support. Remember, most CPAN developers don’t get paid to maintain their modules.

  2. May 8th, 2011 at 16:54 | #2
    Matthew Musgrove :

    To paraphrase you: “I want modern Perl features on my ancient servers.”

    Not correct. I want modern Perl features on modern stable servers. RHEL5 is hardly ancient by any standard. Just because there is something more modern doesn’t mean I have to upgrade immediately. Besides, I’m all for migrating away from Perl 5.6 for example, since Unicode support is nothing to sneeze at. But I’d like to have rationale for moving away from Perl 5.8, which more often than not boils down to “I’d like to have the smart-match operator”. By my standards, a non-issue.

    Matthew Musgrove :

    You can’t make every CPAN developer stick to a specific antiquated version of Perl just because you can’t upgrade. Each CPAN developer is free to pick and choose what Perl versions they support. Remember, most CPAN developers don’t get paid to maintain their modules.

    Yeah, that old point about not being paid for free stuff. Yeah, I know that. And I’m not likely to force anyone to do anything. The problem is: if Mojolicious stops working with Perl 5.8 (and someday it will) I see a 5.8-compatible fork upcoming, which will fragment the community yet again. I usually thought efforts like Mojolicious are meant to strenghten Perl community as a whole, not to split it apart. But everyone is clearly entitled to his own opinion — mine is, that Mojolicious is a great leap forward, which I cannot recommend unconditionally anymore but instead I’d have to check which platform the person in question is running. It’s sad, nothing more. It could have been better, that’s all I say.

  3. Peter Rabbitson
    May 8th, 2011 at 17:03 | #3

    No, he is asking for modern libraries on his ancient (but not that different) perl. There is a fine line between “I can not dev for 5.8.x because I need Regexp::Grammars” and “I can not dev for 5.8.x because it lacks given/when and //=”. The first argument is valid, and any complaints must be accompanied by an extensive and well tested patch. The second “oh shiny” argument is invalid. The general feeling among “old dogs” is that the progressives choose to dev on 5.new solely based on their craving for syntax sugar. This is what this post is (imho) about.

  4. Peter Rabbitson
    May 8th, 2011 at 17:05 | #4

    @rassie Heh, posted before checking what was already commented. GMTA :D

  5. educated_foo
    May 8th, 2011 at 17:14 | #5

    Hey, it’s chromatic’s world, we just live here.

  6. Glen Hinkle
    May 8th, 2011 at 17:20 | #6

    @rassie, I’m not sure you understand exactly what Sebastian meant by ‘deprecating’. Check out the thread…specifically, the last post.

    http://groups.google.com/group/mojolicious/browse_thread/thread/510dcf2219371deb

  7. May 8th, 2011 at 17:40 | #7

    @rassie I get your point, but your tone is way over the top and offensive. Using words like “despise” and saying that devs are giving a ‘big “fuck you!”’ to the community is really not helpful. Could you talk about this in a different way? As a developer behind a lot of widely-used Perl libraries, blog posts like yours are incredibly demotivating.

    Please read http://www.modernperlbooks.com/mt/2011/04/civility-starts-with-me.html and the associated blog posts.

  8. May 8th, 2011 at 18:12 | #8

    It’s no longer happening, deprecation has been reverted, the Perl community is sadly not ready for it. http://mojolicio.us/perldoc?Mojolicious/Guides/FAQ#Why_is_using_Perl_52E82Ex_such_a_bad_idea3F

  9. Matthew Musgrove
    May 8th, 2011 at 18:56 | #9

    @rassie (Random ordering of responses as I thought of things…)

    “RHEL5 is hardly ancient by any standard.” Seriously? It was old when it was released but that’s because you want the stability. Stability and modern are at oppose ends of the tech spectrum.

    “But I’d like to have rationale for moving away from Perl 5.8” Five words: performance enhancements and bug fixes http://perldoc.perl.org/5.10.0/perldelta.html#Performance-Enhancements http://perldoc.perl.org/5.10.0/perldelta.html#Selected-Bug-Fixes http://perldoc.perl.org/5.10.1/perldelta.html#Performance-Enhancements http://perldoc.perl.org/5.10.1/perldelta.html#Selected-Bug-Fixes

    “I want modern Perl features on modern stable servers.” Fair enough. Install a newer Perl such as 5.10.1 which was released in 2009. It’s not the latest but it’s stable. Doing so is easy and doesn’t affect the stability of the server because you don’t replace the system Perl in the process.

    Oh right, you don’t want to incur the cost of regression testing. What happens when RHEL5 is at the end of life and you have to upgrade to get support? Yep, you have to regression test everything and not just your Perl applications. Don’t put off ‘til 2014 what you can do today.

    You still have to incur the cost of that testing at some point and putting it off only increases said cost. As your code base grows, you will need to add more tests. More tests require more man-hours to complete the testing. More man-hours means more money out of pocket and as the years roll on, salaries increase…

    So take a stand today for tomorrow’s bottom line. Fork your code, install a newer version of Perl and start regression testing your Perl application as time allows. You’ll thank yourself later when you have to regression test everything but your Perl applications. Your boss will even thank you if you present it properly.

  10. May 9th, 2011 at 09:46 | #10

    I totally understand your pain as I also have to use older versions of perl though I also think that your wording is very offending. Not only to Sebastian but to the other CPAN authors.

    I think the problem of making it easy for people on old perls to use CPAN needs to be solved. Instead of requiring the CPAN authors to stick to old versions of Perl, IMHO, we should make it easy to “install the latest version that still works on my perl”.

  11. Caldrin
    May 10th, 2011 at 15:16 | #11

    I don’t get the point. So you need to stick to perl5.8 because that’s what came with your RHEL and that’s what you get Redhat support for. Therefore, you can not install perl5.10, a well tested, widely used, stable piece of software. Then how can you install modules from CPAN? You won’t get Redhat support for that either and since they are likely less tested than perl5.10 the risk to break something is much higher.

  12. May 10th, 2011 at 17:40 | #12

    I write code and put it on CPAN because I enjoy writing it and sharing it. If I got yelled at by people demanding that I reduce my enjoyment in favour of their entitlement, I would give serious thought to giving away my maint bits to these people and either forking my own projects or simply not sharing anything at all. “You want this, fine. You get to do the honours.”

  1. No trackbacks yet.