tcllib-devel

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

[Andreas K. <and...@gm...>]

Hi all.

[[
    This is an edited copy of something I posted on the Tcler's Chat
    today. IOW some of you may have seen this already.

    Mailing it around now for wider dispersal / attention.
]]

I have opened the `tcllib-1-21-rc` branch for work on the next Tcllib release, 
1.21.
(It is about 2.5 years since 1.20 was released).

See
	https://core.tcl-lang.org/tcllib/timeline?r=tcllib-1-21-rc

for the timeline.

I am setting a deadline of Fri May 6 for the release work (see below).
The weekend of May 7/8 is when I want to finalize and publish everything.

Currently done:

  - Fixed the `sak review` helper.

  - Fixed a number of packages which were changed, yet did not have
    their version bumped.

  - Bumped the Tcllib main version.
  
  - Generated the initial release README summarizing changes since 1.20.

    See
    https://core.tcl-lang.org/tcllib/file?name=support/releases/history/README-
1.21.txt

    This will be updated as work is done in the coming 1.5 weeks.

Things to still do:

  - Looking at more tickets easy to fix.

  - @arjen - Please keep me informed wrt your progress on the figurate fixes.

  - @pooryorick - Please keep me informed wrt your progress on the mime2 work.

  - @rkeene - Please look at open PKI tickets

  - @hypnotoad - Please look at tickets for your packages (httpd, processman, 
etc. pp.)

  - All/Generally: Please bring tickets felt to be important to my attention.

    Note however: Tickets without repro code and/or patch and/or tests
    are automatically low priority to me.

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.

  2. For all the packages which come in multiple major versions (md5
     IIRC, various struct/math packages, snit, ...) drop, as in,
     remove, anything but the last version. The mime package would be
     an exception to that given that its new major version (v2) would
     have appeared only with 1.21, without a decade or more for users
     to switch.

This release should then be Tcllib 2.0.

-- 
Happy Tcling,
	Andreas Kupries <and...@gm...>
			<https://core.tcl-lang.org/akupries/>
			<https://akupries.tclers.tk/>
	Developer @	SUSE Software Solutions Germany GmbH
-------------------------------------------------------------------------------

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

[Evan R. <er...@uv...>]

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?


Thanks for the consideration.

Evan Rempel

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

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

[Andreas K. <and...@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?

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

I actually still test Tcllib release RCs against 8.5.
8.4 even.

Specifically
	8.4.20
	8.5.19
	8.6.10
	8.7.a4 (*)


(*) Just to look ahead for possible issues.
    Failures there are not blockers and not acted on.

-- 
Happy Tcling,
	Andreas Kupries <and...@gm...>
			<https://core.tcl-lang.org/akupries/>
			<https://akupries.tclers.tk/>
	Developer @	SUSE Software Solutions Germany GmbH
-------------------------------------------------------------------------------

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

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

On Tue, Apr 26, 2022 at 5:39 PM Andreas Kupries <and...@gm...>
wrote:

> I actually still test Tcllib release RCs against 8.5.
> 8.4 even.
>
> Specifically
>         8.4.20
>         8.5.19
>         8.6.10
>         8.7.a4 (*)
>
>
> (*) Just to look ahead for possible issues.
>     Failures there are not blockers and not acted on.
>
>
OK, good to know!  In any case, the fact remains that code (such as
struct::disjointsets) that loaded in Tcl 8.5 on earlier Tcllib releases now
may have declared Tcl 8.6 dependencies. That's sort of a silent regression,
since I'm sure your test process simply ignores packages with a declared
dependency on a newer release.


-- 
73 de ke9tv/2, Kevin