Re: [Tcllib-devel] Tcl 8.2 support

[Lars H. <Lar...@re...>]

This is an old thread, and an issue probably already settled, but it 
just occurred to me that the main argument for the strict 
interpretation is flawed, or requires changes also elsewhere.

On 2008-05-25, Jeff Hobbs wrote:
> Lars Hellström wrote:
>> I can understand a policy of "don't make any changes to patches, or 
>> otherwise restrain your coding style, just for the sake of preserving 
>> compatibility with Tcl 8.x if x<4". I can also understand not wanting 
>> to entertain old Tcl versions just for the sake of testing tcllib 
>> releases, in the hope that someone, somewhere might appreciate it.
>>
>> On the other hand, denying the actual compatibility level of a piece 
>> of software feels rather artificial.
>>
>> Is the catch the uncertainty factor: that one can _presume_ a package 
>> works with Tcl 8.2 based on the features it uses, but won't really 
>> _know_ whether this is the case until having tested it on an actual 
>> Tcl 8.2 interpreter?
> 
> This is the primary reason.  Unless someone else is secretly doing it, 
> tcllib hasn't been tested against anything below 8.4 in a long time.

This seems reasonable as long as one considers only the Tcl version, 
but in this context Tcl is just a package on which there is some 
dependence; one package among many. Hence if this "we can only have 
[package require] for versions actively tested" principle is to be 
taken seriously, then it should be applied also for all other packages, 
should it not?

Well, grepping in tcllib 1.10 finds:

package require Trf 2.0     (in base64/base64.tcl), but I have 2.1.
package require dns 1.0     (in dns/resolv.tcl), but I have 1.3.2.
package require cmdline 1.1 (in htmlparse/htmlparse.tcl), I have 1.3.
package require asn 0.7     (in ldap/ldap.tcl), I have 0.8.1.
package require uri 1.1.5   (in ldap/ldapx.tcl), I have 1.2.1.

and so on; the versions don't match more often than they do match, so 
should all these numbers be raised to the highest version in tcllib, 
because that is the only combination that is tested? Well, the majority 
of all non-Tcl [package require] in tcllib is not for a version lower 
than that currently in tcllib, because the majority of all calls don't 
specify any version at all -- which means every version that ever 
existed or ever will exist of that package is accepted! Is that a 
smaller problem than a deliberate but untested [package require Tcl 8.2]?

The conditional use of C extension packages (such as Trf) complicates 
the matter further, because making use of these then requires running 
the test both with and without the package in question, where the 
"with" case decomposes into separate cases for every version of the 
extension that is not ruled out by the version requirement.

Conclusion: I doubt we have ever conducted tests at the level of rigor 
that this principle aims for.

 > We have had issues where 8.4-isms crept into code that claimed to be
 > "8.2-compliant" and somebody noticed.

Realistically, there will always be bugs in not requiring a high enough 
version of a package (just as there will, more often, be other types of 
  bugs), it only happens for Tcl more often than for the other packages 
because Tcl is far more used.

Lars Hellström