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
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
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.