Re: Interchange 5.12 and raising the Perl version
Mike Heins <[email protected]> Mon, 16 Jul 2018 23:15:24 -0500
| Newsgroups | gmane.comp.web.interchange.users |
|---|---|
| Message-ID | <CACcURn8EaT4V-NYHET3ExQ+NVSfSp=eeZ-CeTi6ku-=6A64EyA@mail.gmail.com> |
--===============1800837074== Content-Type: multipart/alternative; boundary="000000000000fab40005712a313e" --000000000000fab40005712a313e Content-Type: text/plain; charset="UTF-8" +1 On Mon, Jul 16, 2018 at 1:48 PM, Jon Jensen <[email protected]> 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 > [email protected] > http://www.icdevgroup.org/mailman/listinfo/interchange-users > -- Just because something is obviously happening doesn't mean something obvious is happening. --Larry Wall --000000000000fab40005712a313e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">+1<br></div><div class=3D"gmail_extra"><br><div class=3D"g= mail_quote">On Mon, Jul 16, 2018 at 1:48 PM, Jon Jensen <span dir=3D"ltr">&= lt;<a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]</= a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"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 I= nterchange 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 t= o 5.14.1.<br> <br> I will plan to do this unless, within the next 2 weeks, an actively contrib= uting member of our community speaks up to convince the core group that wou= ld be a bad idea, based on the impact to actual production Interchange site= s.<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. Th= at version is nearly 14 years old. For our core Interchange software to sup= port a version that old means:<br> <br> * There is a large variation in which core modules can be counted on, and<b= r> =C2=A0 which versions.<br> <br> * Support for Safe, UTF-8, threading, and other features varies widely<br> =C2=A0 between versions.<br> <br> * The core developers need to support every Perl version in between:<br> =C2=A0 5.8.5, 5.10, 5.12, 5.14, 5.16, 5.18, 5.20, 5.22, 5.24, 5.26, 5.28, w= ith<br> =C2=A0 all the module variations that come with that.<br> <br> The number of actively contributing Interchange developers is small. It inc= reases friction and risk, and decreases progress and simple enjoyment of th= e work, when our contributors have to support such a large number of versio= ns, most of them beyond support end of life and not used by the core develo= pers 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 s= hould be using modern versions that are common and supported in the Perl co= mmunity.<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 &= quot;new" (though already over a decade old!) features rather than bei= ng stuck with an ancient dialect of Perl. Such features that we have been u= nable 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{...},<b= r> =C2=A0 \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 featur= es 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 o= urselves 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 previou= s version 5.26.<br> <br> But the main Linux server distributions RHEL/CentOS, Debian, and Ubuntu, pr= ovide a longer support lifetime for the core packages they distribute, whic= h 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, a= nd most payment gateways have now disabled TLS < 1.2 on their systems.<b= r> <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 th= e OpenSSL library for TLS. So we should only need to support distros that a= lso 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 w= ith 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. U= buntu 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 t= hen 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 o= f annoyances, large and small, that add up.<br> <br> Now a major problem with newer versions of Perl is that they often cause tr= ouble with Safe due to runtime requires and the Encode module. Some catalog= s 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 goin= g 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 t= his during upgrades, and we don't do the rest of the users any favors b= y 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 ge= tting 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 uns= upported older version of Interchange.<br> <br> They can even backport later fixes manually if they want. It's free sof= tware, and they can do what they like with it, but we should not feel oblig= ated to support a large matrix of old versions that are not supported by an= yone 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 versio= ns are not supported by the Perl maintainers nor by any of the current majo= r Linux distros.<br> <br> Interchange is mature and in maintenance mode, it is true. But that does no= t mean that we should leave it stuck in the distant past such that contribu= ting to it requires extensive historical knowledge of what features were su= pported in 10+ year old versions of Perl.<br> <br> In an interchange-users mailing list discussion thread in June 2017:<br> <br> <a href=3D"http://www.icdevgroup.org/pipermail/interchange-users/2017-June/= 055641.html" rel=3D"noreferrer" target=3D"_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=3D"HOEnZb"><font color=3D"#888888"><br> <br> <br> -- <br> Jon Jensen<br> End Point Corporation<br> <a href=3D"https://www.endpoint.com/" rel=3D"noreferrer" target=3D"_blank">= https://www.endpoint.com/</a><br> <br> ______________________________<wbr>_________________<br> interchange-users mailing list<br> <a href=3D"mailto:[email protected]" target=3D"_blank">inter= [email protected]<wbr>rg</a><br> <a href=3D"http://www.icdevgroup.org/mailman/listinfo/interchange-users" re= l=3D"noreferrer" target=3D"_blank">http://www.icdevgroup.org/mail<wbr>man/l= istinfo/interchange-users</a><br> </font></span></blockquote></div><br><br clear=3D"all"><br>-- <br><div clas= s=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><= div>Just because something is obviously happening doesn't mean somethin= g<br>obvious is happening. --Larry Wall<br></div></div></div> </div> --000000000000fab40005712a313e-- --===============1800837074== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ interchange-users mailing list [email protected] http://www.icdevgroup.org/mailman/listinfo/interchange-users --===============1800837074==--