Tcl Source Code

View Ticket
Login
Bounty program for improvements to Tcl and certain Tcl packages.
Ticket UUID: 1703170
Title: TEA_INIT does exact version matching
Type: RFE Version: None
Submitter: dgp Created on: 2007-04-18 18:47:52
Subsystem: 85. tclconfig Assigned To: hobbs
Priority: 5 Medium Severity:
Status: Closed Last Modified: 2010-08-14 01:20:24
Resolution: Wont Fix Closed By: hobbs
    Closed on: 2010-08-13 18:20:24
Description:
This is more a question than a
request actually.  I notice that
TEA_INIT implements exact version
matching.  That is, if the
configure.in file for some package
contains the line:

  TEA_INIT([3.5])

And then the HEAD of tclconfig
(currently marked as TEA 3.6)
is used with autoconf to generate
a configure script for that package.

Then when the configure script runs,
it will spit out a warning about
the mismatch of version numbers.

In other contexts I might expect
version 3.6 of something to satisfy
a requirement of 3.5, but that's
not the kind of matching being done here.
Perhaps version numbers suggesting
that kind of compatibility tracking
ought not be used if that's not the
kind of matching being done?  Or
perhaps TEA_INIT matching should be
revised to conform to expectations
more like those of [package require]?

In light of the exact matching requirement
implemented in TEA_INIT, some guidance
on how package authors ought to maintain
this would be helpful.

If package authors are intended to
update the TEA_INIT() lines in their
configure.in files only when their
package needs require it, then it seems
they will want to have a snapshot copy
of tclconfig that matches their needs,
and they ought not track the HEAD of
tclconfig.  In that case, it would be
helpful for the tclconfig cvs module to
have some cvs tags marking the snapshots
that correspond to a version of TEA, and
even better, tclconfig might provide some
"releases" of TEA support files.

On the other hand if a package is tracking
the HEAD of tclconfig, it seems that any
`cvs update` that brings in a new TEA_VERSION
value needs to prompt an edit of the
TEA_INIT line of that package to maintain
warning-free compatibility.  Some greater
visibility about such changes on the HEAD
of tclconfig might be helpful (an announcement
on a mailing list?).  Or, perhaps
support for a zero-argument form of TEA_INIT
would be better, to permit a maintenance-free
way for the package author to say "any version
is fine", when the package author knows he
will be tracking the latest and greatest.

Or maybe I'm off on all of this, and I just
need someone to point out the better way.
User Comments: hobbs added on 2010-08-14 01:20:24:
allow_comments - 1

I'm going to confirm that since it is only a warning (which the extension dev would see in testing), that this is the behavior I'm looking for.  I want recognition of the new version acknowledged (by adapting configure.in).  Even though this might mean no other changes are required (such as TEA 3.7 -> 3.8), it is just a confirmation of the process.

hobbs added on 2007-07-06 03:49:54:
Logged In: YES 
user_id=72656
Originator: NO

The TEA_VERSION matching with TEA_INIT was added primarily to give users an indication about whether their configure.in is in sync with the tcl.m4 they have obtained (through 'cvs up', copy or whatever).  With updates to TEA that have required compatibility changes (which are few), an update has been sent to the tcl-core mailing list.