> They currently do support 8.4 and I am planning to continue support; > Even > 8.0 I supported > > Any signs that they don't? > > Not to my knowledge. > > One > reason I ask though is in consideration of the possibility of merging Tcl::pTk > and Tcl::Tk, which I have not made progress on. Even if I leave in > compatibility with 8.4, I might only be willing to "actively support" and test > on 8.5 or later.
Good point However even if Tcl::Tk will drop 8.4, Tcl.pm still should support it; OTOH for now we should elaborate a plan of "merging" of Tcl::Tk and Tcl::pTk. In my opinion, nowadays the picture is this: - I see lots of "good" activity on github Tcl::pTk project; I pretty much like it - however IMO there is some, say, 5% of incompatibilities, which will never go away, So if you take random perl/Tk program - will it just run, after you'll replace "use Tk" with "use Tcl::pTk"? mostly - no (correct me if I am wrong) - but perlTk itself is "Tk-804.034" <-- it even mentions 8.4, which you intended to drop, so I see no very deep reason on having 100% compatibility. Syntax is good, but no more than that, 95 is enough (of course other people could have different opinion, I respect that other opinion) Yet, there is another point: Now Tcl::Tk is a single-file perl module, which fully allows perl-tk syntax; it is very tempting to have it single and thin and very lightweight. For me, perl/Tk syntax is preferable (together with pure-tcl) over some perl/Tk module that I could potentially use. To make both projects happy, I would think about following proposal: - I will move that single file of current Tcl::Tk Tcl/Tk.pm into Tcl.pm, renamed somehow. - ... which will be optionally called from Tcl, such as "use Tcl ':perltk'; - (while doing that I will remove lots of unneeded methods from there and will modernize it (no, this does not mean ''use warnings'' at all)) - then you could use Tcl::Tk namespace freely; merge and/or refer /or alias to each other; IDK whether this wins something, all these thoughts are fresh; So perl/Tk syntax will be (optionally) provided by "tcl.pm"; no care of perl/tk compat at all. This will mean Tcl::Tk in its current stage could leave and free space for better compatibility. PS. I must admit I haven't touched codebase of tcl.pm for several months already, but surely I am planning to return to this, soon :)