Re: [Tcllib-devel] Tcllib 1.21 Release To Come, And Further

[Pietro C. <ga...@ga...>]


> On 26 Apr 2022, at 17:21, Andreas Kupries <and...@gm...> wrote:
> 
> 
>>> On 2022-04-26 03:53, Andreas Kupries wrote:
>>> And looking beyond 1.21 my plan is to have a larger cleanup, as in:
>>>  1. Even Tcl 8.5 is end of life for oever 6 years now (8.5.19 was 2016-02-12).
>>>     Let alone 8.4 and older.
>>>     Some of the packages in Tcllib still declare 8.2 as min requirement/
>>>     I want to declare everything before 8.6 as unsupported now.
>>>     There was enough time to switch.
>>>     That will make development much easier as there is no need to
>>>     think about if a command, function, syntax is supported by the
>>>     declared min-version of the package, or not. Recently seen with a
>>>     patch using the `max` function. Does not exist in 8.4.
>> Redhat Enterprise Linux 7 uses tcl 8.5
>> Redhat Enterprise Linux 7 is a supported product through 2024, and with
>> extended support until 2026.
>> https://access.redhat.com/support/policy/updates/errata
>> If there isn't a technical reason to increase the minimum tcl
>> requirement can I request that a minimum of 8.5 be used until 2026?
> 
> Fair argument.
> 
> Are there __strong objections__ (i.e. with good arguments) against keeping to 
> 8.5 as the minimum over 8.6 ?
> 
> If not I would change the plans for after 1.21 to go with 8.5.

Not very strong, but it feels weird to me that long-term distros would push the maintenance burden upstreams.

I contribute(d) very little to tcl/tcllib, but having to be retro-compatible with 8.5 has already meant you Andrea had to modify a patch of mine.

Is the message really going to be that 8.5 is unmaintained but tcllib still needs to run on it?

If users of RHEL can install a newer tcllib, I guess they can surely install a newer Tcl?

-- 
Pietro Cerutti