[ic] Interchange 5.12 and raising the Perl version

Tue Jul 17 09:33:41 UTC 2018

On 07/16/2018 08:48 PM, Jon Jensen wrote:
> Interchangers,
> 
> With Perl 5.28.0 recently having been released, I'm thinking again of Interchange and its relationship to modern Perl.
> 
> TL;DR:
> 
> 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.
> 
> 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.

+1 for the change.

Regards
         Racke

> 
> Now for the detailed rationale behind this change:
> 
> 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:
> 
> * There is a large variation in which core modules can be counted on, and
>   which versions.
> 
> * Support for Safe, UTF-8, threading, and other features varies widely
>   between versions.
> 
> * The core developers need to support every Perl version in between:
>   5.8.5, 5.10, 5.12, 5.14, 5.16, 5.18, 5.20, 5.22, 5.24, 5.26, 5.28, with
>   all the module variations that come with that.
> 
> 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.
> 
> 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.
> 
> 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:
> 
> * modern Unicode versions supporting newer characters (especially non-BMP)
> * feature pragma
> * new regular expression features /xx, /u, /a, /ee, /r, \N{...}, \g{...},
>   \k<...>, \K, \R, \X, \b{}, \G, named captures, (?{ code }) and many others
> * the // operator
> * subroutine signatures
> * __SUB__
> * <<>>
> * variable aliasing
> * lexical subroutines
> * more useful functions in core modules such as List::Util
> * and many more
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.)
> 
> 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.
> 
> 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.
> 
> 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.
> 
> The lowest common denominator of the above is 5.14.1. That is still 7 years old, from 2011!
> 
> By way of comparison:
> 
> 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.
> 
> Perl 5.8.5 was released in July 2004, and about 4 years later in late 2008 Interchange began requiring it.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> In an interchange-users mailing list discussion thread in June 2017:
> 
> http://www.icdevgroup.org/pipermail/interchange-users/2017-June/055641.html
> 
> 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.
> 
> So now with Interchange 5.12 we should make this change. It is time.
> 
> Thanks,
> Jon
> 
> 


-- 
Ecommerce and Linux consulting + Perl and web application programming.
Debian and Sympa administration. Provisioning with Ansible.