|Title:||TEA_INIT does exact version matching|
|Submitter:||dgp||Created on:||2007-04-18 18:47:52|
|Subsystem:||85. tclconfig||Assigned To:||hobbs|
|Status:||Closed||Last Modified:||2010-08-14 01:20:24|
|Resolution:||Wont Fix||Closed By:||hobbs|
|Closed on:||2010-08-13 18:20:24|
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.
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.