<div dir="ltr">+1<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 16, 2018 at 1:48 PM, Jon Jensen <span dir="ltr"><<a href="mailto:jon@endpoint.com" target="_blank">jon@endpoint.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Interchangers,<br>
<br>
With Perl 5.28.0 recently having been released, I'm thinking again of Interchange and its relationship to modern Perl.<br>
<br>
TL;DR:<br>
<br>
It is time for us to finally release Interchange 5.12, and before we do so, I would like to raise Interchange's minimum required version of Perl to 5.14.1.<br>
<br>
I will plan to do this unless, within the next 2 weeks, an actively contributing member of our community speaks up to convince the core group that would be a bad idea, based on the impact to actual production Interchange sites.<br>
<br>
Now for the detailed rationale behind this change:<br>
<br>
Interchange has for many years required at a minimum Perl version 5.8.5. That version is nearly 14 years old. For our core Interchange software to support a version that old means:<br>
<br>
* There is a large variation in which core modules can be counted on, and<br>
  which versions.<br>
<br>
* Support for Safe, UTF-8, threading, and other features varies widely<br>
  between versions.<br>
<br>
* The core developers need to support every Perl version in between:<br>
  5.8.5, 5.10, 5.12, 5.14, 5.16, 5.18, 5.20, 5.22, 5.24, 5.26, 5.28, with<br>
  all the module variations that come with that.<br>
<br>
The number of actively contributing Interchange developers is small. It increases friction and risk, and decreases progress and simple enjoyment of the work, when our contributors have to support such a large number of versions, most of them beyond support end of life and not used by the core developers ourselves anywhere in production.<br>
<br>
Because of this it is becoming urgent for Interchange to get with the times on the Perl front. Perl is the foundation Interchange is built on, so we should be using modern versions that are common and supported in the Perl community.<br>
<br>
We should do what we can to make working with a current OS, Perl, and CPAN modules, as smooth as possible. The core developers should be able to use "new" (though already over a decade old!) features rather than being stuck with an ancient dialect of Perl. Such features that we have been unable to use include:<br>
<br>
* modern Unicode versions supporting newer characters (especially non-BMP)<br>
* feature pragma<br>
* new regular expression features /xx, /u, /a, /ee, /r, \N{...}, \g{...},<br>
  \k<...>, \K, \R, \X, \b{}, \G, named captures, (?{ code }) and many others<br>
* the // operator<br>
* subroutine signatures<br>
* __SUB__<br>
* <<>><br>
* variable aliasing<br>
* lexical subroutines<br>
* more useful functions in core modules such as List::Util<br>
* and many more<br>
<br>
I don't think any of us has a burning desire to use any of these features every time we make a change to core Interchange, but I don't want to have to think any more about the subset of the language we have to limit ourselves to for ancient Perl.<br>
<br>
How do we decide which minimum Perl version to support? Currently the Perl developers themselves only support the current version 5.28 and the previous version 5.26.<br>
<br>
But the main Linux server distributions RHEL/CentOS, Debian, and Ubuntu, provide a longer support lifetime for the core packages they distribute, which includes Perl. So we will want to go earlier to include all Perl versions still supported by the main Linux server distros.<br>
<br>
Further, TLS 1.2 is required by the PCI DSS ecommerce payments standards, and most payment gateways have now disabled TLS < 1.2 on their systems.<br>
<br>
For an HTTPS client to use TLS 1.2, it must be based on a TLS library that supports it. The vast majority of Interchange sites run on Linux and use the OpenSSL library for TLS. So we should only need to support distros that also support TLS 1.2, making them useful for ecommerce. (Setting aside hand-built newer OpenSSL on older systems, a hack that almost certainly would be unmaintained and exposed to later security problems.)<br>
<br>
RHEL/CentOS 6 is the oldest supported in that family, and includes TLS 1.2 and Perl 5.14.1. RHEL/CentOS 7 comes with Perl 5.16.3.<br>
<br>
Debian 7 is the oldest supported in its family, in its LTS phase. It came with Perl 5.14.2. Debian 8 comes with Perl 5.20.2, and 9 with 5.24.1.<br>
<br>
Ubuntu 14.04 LTS is the oldest supported in its family, with Perl 5.18.2. Ubuntu 16.04 LTS has 5.22.1, and Ubuntu 18.04 LTS has 5.26.0.<br>
<br>
The lowest common denominator of the above is 5.14.1. That is still 7 years old, from 2011!<br>
<br>
By way of comparison:<br>
<br>
Perl 5.6.0 was released in March 2000, and less than 3 years later in early 2003 Interchange began requiring 5.6 or later.<br>
<br>
Perl 5.8.5 was released in July 2004, and about 4 years later in late 2008 Interchange began requiring it.<br>
<br>
If we bump our minimum version requirement only up to 5.14.1, that will be the most tolerant we have ever been upon requiring a newer version: a full 7 years old. We can't use OpenSSL that old. OpenSSH that old doesn't work with newer key types and ciphers. Etc.<br>
<br>
Imagine if, in the year 2008, we had still been trying to support a 13-year-old Perl version. That would mean Perl 5.002. Anyone who was around back then can imagine what a pain that would be. Perl programmers who are used to more recent Perl versions now feel the same way. Old versions cause lots of annoyances, large and small, that add up.<br>
<br>
Now a major problem with newer versions of Perl is that they often cause trouble with Safe due to runtime requires and the Encode module. Some catalogs may have to switch to using global Perl rather than Safe.<br>
<br>
That is highly annoying, but since that is the direction Perl has been going for many years, it is not a temporary situation we can wait out. We need to cope with it and completely make the move as a group.<br>
<br>
Most of us supporting active ecommerce site have already had to deal with this during upgrades, and we don't do the rest of the users any favors by not having Interchange work comfortably with current Perl. We should now accept that this is the way Perl has gone and deal with the new reality.<br>
<br>
The old OS versions are dead. Moving to a new supported OS version means getting a more current Perl build. Most people on an old Perl would also have an end of life distro and CPAN modules. If that's what someone wants, they're of course free to do that, and they can just as well use an unsupported older version of Interchange.<br>
<br>
They can even backport later fixes manually if they want. It's free software, and they can do what they like with it, but we should not feel obligated to support a large matrix of old versions that are not supported by anyone else and that make our open source contributions a pain.<br>
<br>
This may require some work during upgrades, so the new Interchange release being a major number change to 5.12 will indicate that it is an update that shouldn't be dropped in place blindly.<br>
<br>
I consider our default move now and in the future during major Interchange releases to be increasing the minimum Perl version because the older versions are not supported by the Perl maintainers nor by any of the current major Linux distros.<br>
<br>
Interchange is mature and in maintenance mode, it is true. But that does not mean that we should leave it stuck in the distant past such that contributing to it requires extensive historical knowledge of what features were supported in 10+ year old versions of Perl.<br>
<br>
In an interchange-users mailing list discussion thread in June 2017:<br>
<br>
<a href="http://www.icdevgroup.org/pipermail/interchange-users/2017-June/055641.html" rel="noreferrer" target="_blank">http://www.icdevgroup.org/pipe<wbr>rmail/interchange-users/2017-<wbr>June/055641.html</a><br>
<br>
I first laid out the case above. There was some opposition, and I asked for those opposed to provide evidence of specific cases where this would cause real active users hardship. No such examples were provided.<br>
<br>
So now with Interchange 5.12 we should make this change. It is time.<br>
<br>
Thanks,<br>
Jon<span class="HOEnZb"><font color="#888888"><br>
<br>
<br>
-- <br>
Jon Jensen<br>
End Point Corporation<br>
<a href="https://www.endpoint.com/" rel="noreferrer" target="_blank">https://www.endpoint.com/</a><br>
<br>
______________________________<wbr>_________________<br>
interchange-users mailing list<br>
<a href="mailto:interchange-users@icdevgroup.org" target="_blank">interchange-users@icdevgroup.o<wbr>rg</a><br>
<a href="http://www.icdevgroup.org/mailman/listinfo/interchange-users" rel="noreferrer" target="_blank">http://www.icdevgroup.org/mail<wbr>man/listinfo/interchange-users</a><br>
</font></span></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Just because something is obviously happening doesn't mean something<br>obvious is happening. --Larry Wall<br></div></div></div>
</div>