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

[Kevin K. <kev...@gm...>]

On Tue, Apr 26, 2022 at 9:27 AM Evan Rempel <er...@uv...> wrote:

> 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?
>

2026 is fourteen years after Tcl 8.6 became the current release, and ten
years after 8.5's end of life. It always struck me as peculiar that RHEL 7
shipped with a two-years-out-of-date Tcl from the start.

It doesn't seem unreasonable to me to require that if you're going to use
an obsolete Tcl, you have to use an obsolete Tcllib.

If I'm editing a Tcllib package, I generally have it assert a dependency
against the earliest point release that I've tested against - and I don't
routinely test against end-of-life releases. 8.5 has been at end-of-life
for long enough that I'm not always aware of whether I'm using
8.6-dependent functionality, and I certainly don't avoid introducing
8.6-dependent features for the sake of downstream extended-support
releases, so updating the dependency is a routine action.

For instance, in 2018 I introduced an 8.6 dependency into
struct::disjointset - because the existing implementation didn't actually
provide a disjoint-sets data structure. Apparently, the GSoC student who
introduced it was none to clear on what a disjoint-sets data structure
actually was. With 8.5 already at end of life, I had no qualms whatever
about using TclOO features in the implementation and asserting an 8.6
dependency.  This would, however, definitely be a regression if someone
were to install a current Tcllib on top of Tcl 8.5, since the previous
version, ineffective though it was, was satisfied by 8.5 (or even, if
memory serves, 8.4).

If someone wants to take a branch off an earlier Tcllib release and
maintain it with bug fixes, they're welcome to do so. There are even Tcllib
maintainers who would consider providing paid support. (I'm not one; I'm
semi-retired and working part-time for a single employer, not looking for
new business.)

I'd contend that the last few Tcllib releases would be pretty dodgy against
8.5, and package authors are likely to have overlooked updating the Tcl
version dependency. I surely don't think you can expect many packages
actually to have been tested against such an old release. Andreas could
probably recover information about when Tcllib's release process stopped
testing on 8.5.

-- 
73 de ke9tv/2, Kevin