[ic] Interchange 5.12 and raising the Perl version

Tue Jul 17 04:15:24 UTC 2018

+1

On Mon, Jul 16, 2018 at 1:48 PM, Jon Jensen <jon at endpoint.com> 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.
>
> 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
>
>
> --
> Jon Jensen
> End Point Corporation
> https://www.endpoint.com/
>
> _______________________________________________
> interchange-users mailing list
> interchange-users at icdevgroup.org
> http://www.icdevgroup.org/mailman/listinfo/interchange-users
>

-- 
Just because something is obviously happening doesn't mean something
obvious is happening. --Larry Wall
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.icdevgroup.org/pipermail/interchange-users/attachments/20180716/13d59808/attachment.html>