Mailing List Archive

On 23/06/17 19:20, Stefan Hornburg (Racke) wrote:
>
> Hallo David,
>
> thanks very much on your effort to clean up Interchange!
>
> I think the // operator isn't present in older Perls.
>
>> + $pat = $Global::AllowedFileRegex->{$Vend::Cat // ''}

Good catch, yeah, it needs to be changed to:
$pat = $Global::AllowedFileRegex->{defined $Vend::Cat ? $Vend::Cat : ''}


Peter

_______________________________________________
interchange-users mailing list
interchange-users@icdevgroup.org
http://www.icdevgroup.org/mailman/listinfo/interchange-users

On 23/06/17 21:34, Peter wrote:
> On 23/06/17 19:20, Stefan Hornburg (Racke) wrote:
>>
>> Hallo David,
>>
>> thanks very much on your effort to clean up Interchange!
>>
>> I think the // operator isn't present in older Perls.
>>
>>> + $pat = $Global::AllowedFileRegex->{$Vend::Cat // ''}
>
> Good catch, yeah, it needs to be changed to:
> $pat = $Global::AllowedFileRegex->{defined $Vend::Cat ? $Vend::Cat : ''}

...or in this case you could probably just use || instead of //.


Peter

_______________________________________________
interchange-users mailing list
interchange-users@icdevgroup.org
http://www.icdevgroup.org/mailman/listinfo/interchange-users

> On Jun 23, 2017, at 2:20 AM, Stefan Hornburg (Racke) <racke@linuxia.de> wrote:
>
> Hallo David,
>
> thanks very much on your effort to clean up Interchange!
>
> I think the // operator isn't present in older Perls.

I think 5.10 introduced this; I will change it to ‘’ as Peter suggested, however practically speaking I’d expect anyone using IC at this point to be on CentOS 7+ due to TLS issues, so we could probably safely increase the minimum perl version in practice to the min(distributed version of perl in CentOS 7, equivalent Debian TLS-supporting release).

Best,

David
--
David Christensen
End Point Corporation
david@endpoint.com
785-727-1171




_______________________________________________
interchange-users mailing list
interchange-users@icdevgroup.org
http://www.icdevgroup.org/mailman/listinfo/interchange-users

On Fri, 23 Jun 2017, David Christensen wrote:

>> thanks very much on your effort to clean up Interchange!
>>
>> I think the // operator isn't present in older Perls.
>
> I think 5.10 introduced this; I will change it to ‘’ as Peter suggested,
> however practically speaking I’d expect anyone using IC at this point to
> be on CentOS 7+ due to TLS issues, so we could probably safely increase
> the minimum perl version in practice to the min(distributed version of
> perl in CentOS 7, equivalent Debian TLS-supporting release).

David makes a good point: Because TLS 1.2 is required for PCI DSS, and
because older Perl systems are built on older OS/distros with old OpenSSL,
and because almost all Interchange usage is for ecommerce, it is probably
a good time for us to consider raising the minimum Perl version. We have
not done this for many years, so it's a good time anyway. We should
increase the Interchange release to 5.12 to indicate the break in backward
compatibility.

RHEL/CentOS 6 is the oldest supported in that family, and include 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 is the oldest supported, with Perl 5.18.2. Ubuntu 16.04 has
5.22.1.

Based on the lowest common denominator of the above, I propose we increase
the minimum Perl version to 5.14.1. That's still 6 years old, from 2011!

Pros of increasing the Perl version:

* build on a more current Perl + core module + CPAN module base, requiring
fewer checks to see if a Perl module is installed

* be able to use "new" (since over 10 years ago!) features such as the //
operator

* have more modern Unicode support

* reduce number of major versions we have to support / test on

Cons of increasing the Perl version:

* users wanting to stay on old versions won't be able to upgrade past
5.10.x

What do the rest of you think?

Jon


--
Jon Jensen
End Point Corporation
https://www.endpoint.com/

> [snip]

> What do the rest of you think?

Probably obvious my opinion on it, but +1 to move it to 5.14.1 (I’d even say as long as we’re increasing it, forget Deb 7 and just go with 5.16, but that’s just me); if you’re willing to upgrade your TLS, want to upgrade your IC, but unwilling to install a new version of perl it makes no sense here. At some point you have to start moving forward.
--
David Christensen
End Point Corporation
david@endpoint.com
785-727-1171




_______________________________________________
interchange-users mailing list
interchange-users@icdevgroup.org
http://www.icdevgroup.org/mailman/listinfo/interchange-users

On Fri, 23 Jun 2017, David Christensen wrote:

> Probably obvious my opinion on it, but +1 to move it to 5.14.1 (I’d even
> say as long as we’re increasing it, forget Deb 7 and just go with 5.16,
> but that’s just me);

You may have missed in my message that RHEL/CentOS 6 are also on 5.14.1,
and those are still supported for a few more years. IMO that's as new as
we should go right now.

> if you’re willing to upgrade your TLS, want to upgrade your IC, but
> unwilling to install a new version of perl it makes no sense here. At
> some point you have to start moving forward.

Indeed.

Jon

Quoting Jon Jensen (jon@endpoint.com):
> On Fri, 23 Jun 2017, David Christensen wrote:
>
> >>thanks very much on your effort to clean up Interchange!
> >>
> >>I think the // operator isn't present in older Perls.
> >
> >I think 5.10 introduced this; I will change it to ?????? as Peter
> >suggested, however practically speaking I???d expect anyone using
> >IC at this point to be on CentOS 7+ due to TLS issues, so we could
> >probably safely increase the minimum perl version in practice to
> >the min(distributed version of perl in CentOS 7, equivalent Debian
> >TLS-supporting release).
>
> David makes a good point: Because TLS 1.2 is required for PCI DSS,
> and because older Perl systems are built on older OS/distros with
> old OpenSSL, and because almost all Interchange usage is for
> ecommerce, it is probably a good time for us to consider raising the
> minimum Perl version. We have not done this for many years, so it's
> a good time anyway. We should increase the Interchange release to
> 5.12 to indicate the break in backward compatibility.
>
> RHEL/CentOS 6 is the oldest supported in that family, and include
> 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 is the oldest supported, with Perl 5.18.2. Ubuntu 16.04
> has 5.22.1.
>
> Based on the lowest common denominator of the above, I propose we
> increase the minimum Perl version to 5.14.1. That's still 6 years
> old, from 2011!
>
> Pros of increasing the Perl version:
>
> * build on a more current Perl + core module + CPAN module base,
> requiring fewer checks to see if a Perl module is installed
>
> * be able to use "new" (since over 10 years ago!) features such as
> the // operator
>
> * have more modern Unicode support
>
> * reduce number of major versions we have to support / test on

I am against this unless there is significant feature content
added by increasing the minimum version. Allowing // in one or
two places doesn't meet that bar to me.

I also note that there are plenty of people who have built
their own Perl to use IC.

If you go above 5.8, you are basically consiging yourself to
using global Perl, as you will have myriad runtime require
problems introduced by 5.10 and above.

>
> Cons of increasing the Perl version:
>
> * users wanting to stay on old versions won't be able to upgrade
> past 5.10.x

There are a number of non-commerce IC implementations which may
want to upgrade.

I don't worry too much about it, but I would like it to be for real
reasons, not one or two uses of //.

--
Mike Heins
End Point -- Expert Internet Consulting http://www.endpoint.com/
phone +1.765.253.4194 <mikeh@endpoint.com>

Find the grain of truth in criticism, chew it, and swallow
it. -- anonymous

_______________________________________________
interchange-users mailing list
interchange-users@icdevgroup.org
http://www.icdevgroup.org/mailman/listinfo/interchange-users

On Fri, 23 Jun 2017, Mike Heins wrote:

>> David makes a good point: Because TLS 1.2 is required for PCI DSS, and
>> because older Perl systems are built on older OS/distros with old
>> OpenSSL, and because almost all Interchange usage is for ecommerce, it
>> is probably a good time for us to consider raising the minimum Perl
>> version. We have not done this for many years, so it's a good time
>> anyway. We should increase the Interchange release to 5.12 to indicate
>> the break in backward compatibility.
>>
>> RHEL/CentOS 6 is the oldest supported in that family, and include 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 is the oldest supported, with Perl 5.18.2. Ubuntu 16.04
>> has 5.22.1.
>>
>> Based on the lowest common denominator of the above, I propose we
>> increase the minimum Perl version to 5.14.1. That's still 6 years old,
>> from 2011!
>
> I am against this unless there is significant feature content added by
> increasing the minimum version. Allowing // in one or two places doesn't
> meet that bar to me.

I certainly understand the desire to avoid change for change's sake. It's
tedious dealing with upgrades anyway, without adding unnecessary pain.
There's a balance to be struck between bleeding-edge and dead.

This is a lot bigger than // - that's just one example of an over
decade-old basic Perl operator that we still can't use in core
Interchange. Even without making a big list of desired newer Perl features
we want to use, it's tiresome to be stuck on such ancient perls and have
to keep track of what syntax worked in the old days and what didn't.

The only supported versions of Perl right now are 5.24 and 5.26.
Everything else is end of life. The reason we can sanely support back to
5.14 is the long-term support Linux distros maintain their old versions
with backported patches, so at least serious security and bug fixes are
covered there. Anyone building their own perl should be watching those
Linux perl maintainers' release notes to see if there are important things
that should be backported to their own perl.

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've ever been upon requiring a newer version: a full 6
years old. We can't use OpenSSL that old. Web servers that old won't
support HTTP/2. OpenSSH that old doesn't work with newer key types. 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. To those who are
used to more recent Perl versions now, it's the same feeling. Lots of
little annoyances that add up.

> If you go above 5.8, you are basically consiging yourself to using
> global Perl, as you will have myriad runtime require problems introduced
> by 5.10 and above.

That is true, and it is highly annoying. Since it's clearly not a
temporary blip, I think we need to cope with it and completely make the
move as a group. Most of us have already had to do that during upgrades,
and we're not doing the rest of the userbase any favors by not having
Interchange work comfortably with current Perl.

The old OS versions are dead. Moving to a new supported OS version should
mean getting a more current Perl build. Most people on an old Perl would
also have an end of life distro, Perl, and CPAN modules. If that's what
someone wants, they're of course free to do that, and can just as well use
an unsupported older version of Interchange. And even backport later fixes
if they want.

I didn't think I cared that much about this but apparently I do, based on
how long this is getting. I feel it is becoming urgent for Interchange to
get with the times on the Perl front.

Interchange is nothing without Perl. If everything has to be global to
work with newer Perl versions, then we should just accept that's the way
things have gone with Perl and deal with it. We should do what we can to
make working with a current OS, Perl, CPAN modules, as easy as possible,
since most people on ancient versions aren't upgrading their Interchange
either.

So everyone please speak up on this: Who is still using Interchange with
Perl older than 5.14.1 and why?

If the only reason is that it's running on an end-of-life server OS that
you need to migrate away from anyway: Have you tried to keep using the
outdated, unsupported Perl on a newer server OS? Have you gotten the old
CPAN modules to work with newer glibc and other libraries?

Jon


--
Jon Jensen
End Point Corporation
https://www.endpoint.com/

_______________________________________________
interchange-users mailing list
interchange-users@icdevgroup.org
http://www.icdevgroup.org/mailman/listinfo/interchange-users

Quoting Jon Jensen (jon@endpoint.com):
> On Fri, 23 Jun 2017, Mike Heins wrote:
>
> > > David makes a good point: Because TLS 1.2 is required for PCI DSS,
> > > and because older Perl systems are built on older OS/distros with
> > > old OpenSSL, and because almost all Interchange usage is for
> > > ecommerce, it is probably a good time for us to consider raising the
> > > minimum Perl version. We have not done this for many years, so it's
> > > a good time anyway. We should increase the Interchange release to
> > > 5.12 to indicate the break in backward compatibility.
> > >
> > > RHEL/CentOS 6 is the oldest supported in that family, and include
> > > 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 is the oldest supported, with Perl 5.18.2. Ubuntu 16.04
> > > has 5.22.1.
> > >
> > > Based on the lowest common denominator of the above, I propose we
> > > increase the minimum Perl version to 5.14.1. That's still 6 years
> > > old, from 2011!
> >
> > I am against this unless there is significant feature content added by
> > increasing the minimum version. Allowing // in one or two places doesn't
> > meet that bar to me.

Seeing as very little active development happens on the IC core these
days, we aren't going to gain much by using newer Perl features. If you
wish to use newer features in your custom development, then that can be
done, of course.

Further, I don't see why we would want to limit our user base by
requiring a more-recent Perl version.

There are plenty of CPAN module that still provide backwards-
compatibility for very old versions of Perl. It's not a matter of
creating that compatibility -- we already have it. So I see no reason to
abadon that now.

If you can't get the current version of IC to run on older Perls that we
claim to support, then that's another matter.

-1

--
Josh Lavin
End Point Corporation

_______________________________________________
interchange-users mailing list
interchange-users@icdevgroup.org
http://www.icdevgroup.org/mailman/listinfo/interchange-users

On Mon, 26 Jun 2017, Josh Lavin wrote:

> I don't see why we would want to limit our user base by requiring a
> more-recent Perl version.

As I asked in my other lengthy follow-up:

Please explain how it limits our userbase to require a Perl version that
is available in every supported distro release.

Who is actually using a public-facing website on an unsupported Linux
version, and why should we hold back Interchange for them?

Jon


--
Jon Jensen
End Point Corporation
https://www.endpoint.com/

_______________________________________________
interchange-users mailing list
interchange-users@icdevgroup.org
http://www.icdevgroup.org/mailman/listinfo/interchange-users

On 27/06/17 11:06, Jon Jensen wrote:
> Please explain how it limits our userbase to require a Perl version that
> is available in every supported distro release.

Should I point out now that RHEL 5 is currently supported by Red Hat
with an ELS subscription and will be until the end of November 2020 and
that this comes with perl 5.8.8?

> Who is actually using a public-facing website on an unsupported Linux
> version, and why should we hold back Interchange for them?

I'm not and I'm really don't have a personal issue with this change, but
given that IC 5 is currently in a maintenance support stage, we should
be focusing more on supporting existing installs rather than enabling a
lot of future work on this. I would like to see a push to get more
people started on IC 6 and get a stable release with a decent set of
instructions out for that. IC 6 is where we should be looking for
forward momentum, IC 5 should keep backwards compatibility, support for
bug and especially security fixes and the occasional new feature where
we can do so without breaking existing installs.


Peter

_______________________________________________
interchange-users mailing list
interchange-users@icdevgroup.org
http://www.icdevgroup.org/mailman/listinfo/interchange-users

On Tue, 27 Jun 2017, Peter wrote:

> On 27/06/17 11:06, Jon Jensen wrote:
>> Please explain how it limits our userbase to require a Perl version that
>> is available in every supported distro release.
>
> Should I point out now that RHEL 5 is currently supported by Red Hat
> with an ELS subscription and will be until the end of November 2020 and
> that this comes with perl 5.8.8?

Sure. And how many actual RHEL 5 + extra paid ELS subscriptions do you
work with?

CentOS 5 and normal RHEL are the past.

>> Who is actually using a public-facing website on an unsupported Linux
>> version, and why should we hold back Interchange for them?
>
> I'm not and I'm really don't have a personal issue with this change, but
> given that IC 5 is currently in a maintenance support stage, we should
> be focusing more on supporting existing installs rather than enabling a
> lot of future work on this. I would like to see a push to get more
> people started on IC 6 and get a stable release with a decent set of
> instructions out for that. IC 6 is where we should be looking for
> forward momentum, IC 5 should keep backwards compatibility, support for
> bug and especially security fixes and the occasional new feature where
> we can do so without breaking existing installs.

Interchange 6 has nothing to do with Interchange 5, just as Perl 6 has
nothing to do with Perl 5.

I deal with dozens of active Interchange 5 sites. I deal with zero
Interchange 6 sites, and don't see that changing in the foreseeable
future.

The reality now is that Interchange 5 is complete and has a large
userbase, and Interchange 6 is incomplete and has very few users. You
don't put the old thing out to pasture till the new thing is mature.
Again, the lessons of Perl 6 vs. 5 apply here.

Interchange 5 needs to continue to adapt and evolve for years to come
because it's actually used by real businesses. That includes the core.

Sure, we can make extra work dealing with old versions' syntax and extra
testing. But I don't think we have the resources to burn on it.

Jon


--
Jon Jensen
End Point Corporation
https://www.endpoint.com/

_______________________________________________
interchange-users mailing list
interchange-users@icdevgroup.org
http://www.icdevgroup.org/mailman/listinfo/interchange-users

> On Jun 26, 2017, at 9:48 PM, Jon Jensen <jon@endpoint.com> wrote:
>
> On Tue, 27 Jun 2017, Peter wrote:
>
>> On 27/06/17 11:06, Jon Jensen wrote:
>>> Please explain how it limits our userbase to require a Perl version that
>>> is available in every supported distro release.
>>
>> Should I point out now that RHEL 5 is currently supported by Red Hat
>> with an ELS subscription and will be until the end of November 2020 and
>> that this comes with perl 5.8.8?
>
> Sure. And how many actual RHEL 5 + extra paid ELS subscriptions do you work with?
>
> CentOS 5 and normal RHEL are the past.

Have we reached any consensus on increasing the minimum perl version? It sounds like opinions were fairly mixed here, with some in favor and some against.

Best,

David
--
David Christensen
End Point Corporation
david@endpoint.com
785-727-1171




_______________________________________________
interchange-users mailing list
interchange-users@icdevgroup.org
http://www.icdevgroup.org/mailman/listinfo/interchange-users

On Tue, 11 Jul 2017, David Christensen wrote:

> Have we reached any consensus on increasing the minimum perl version?
> It sounds like opinions were fairly mixed here, with some in favor and
> some against.

I think our default move should be to increase the minimum perl version
because the older versions are not supported by the Perl maintainers nor
by any of the current major server operating systems.

Merely because Interchange is in maintenance mode 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.

I asked for those who opposed increasing the minimum version to provide
evidence of specific cases where this would cause real active users
hardship, but we have not seen any replies so far.

Jon


--
Jon Jensen
End Point Corporation
https://www.endpoint.com/

_______________________________________________
interchange-users mailing list
interchange-users@icdevgroup.org
http://www.icdevgroup.org/mailman/listinfo/interchange-users

On 07/12/2017 06:52 PM, Jon Jensen wrote:
> On Tue, 11 Jul 2017, David Christensen wrote:
>
>> Have we reached any consensus on increasing the minimum perl version? It sounds like opinions were fairly mixed here,
>> with some in favor and some against.
>
> I think our default move should be to increase the minimum perl version because the older versions are not supported by
> the Perl maintainers nor by any of the current major server operating systems.
>
> Merely because Interchange is in maintenance mode 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.
>
> I asked for those who opposed increasing the minimum version to provide evidence of specific cases where this would
> cause real active users hardship, but we have not seen any replies so far.
>
> Jon
>
>

I certainly not oppose increasing the minimum version based on active instances on the grounds that my installations
have fairly recent Perl versions (either using Debian's Perl or brewed Perls).

Also I would love to see a new release :-)

Regards
Racke

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

_______________________________________________
interchange-users mailing list
interchange-users@icdevgroup.org
http://www.icdevgroup.org/mailman/listinfo/interchange-users