tcl 8.4 support

tcl 8.4 support

Post by Amit Zaro » Fri, 17 Oct 2008 14:40:47


Hi all,
Wanted to know if anyone has any idea, when tcl 8.4.x release stream
will stop being active?
I am guessing after 8.6 is released!

-Amit
 
 
 

tcl 8.4 support

Post by Don Porte » Fri, 17 Oct 2008 22:56:32


It's already well below "active". All the development energy is
on 8.5.* and the 8.6alphas. Just an occasional bugfix backport
gets onto the 8.4 branch these days. Best you can say about 8.4.*
is that it's not quite dead yet.

Sometime during the 8.6 beta sequence, I will make a release of 8.4.20
to get the collected bug fixes out. That release will be marked "final"
and there will be no more TCT releases of Tcl 8.4.*.

It would not surprise me to see various redistributors of Tcl/Tk
continue offering bugfix maintenance of their repackagings. Check
with your supplier.

--
| Don Porter Mathematical and Computational Sciences Division |
| XXXX@XXXXX.COM Information Technology Laboratory |
| http://www.yqcomputer.com/ ~DPorter/ NIST |
|______________________________________________________________________|

 
 
 

tcl 8.4 support

Post by David Grav » Fri, 17 Oct 2008 23:44:38


About a year back I built 7.6p2 for a "special purpose" ;) But replaced
it later with tinytcl.

Tcl never dies; fixes just keep getting back ported.
 
 
 

tcl 8.4 support

Post by Amit Zaro » Sat, 18 Oct 2008 14:19:41

Thanks! What about 8.5, I am yet to deploy it on our application. How
long will this branch remain Active. I am hoping that there are not
many disruptive changes in the next release.
 
 
 

tcl 8.4 support

Post by Gerald W. » Sat, 18 Oct 2008 22:42:13


If your application is pure Tcl, then you rarely have disruptive changes.

If you are also using C then you may have a few every couple of years.

You should never have any with bug fixes.





--
+------------------------------------------------------------------------+
| Gerald W. Lester |
|"The man who fights for his ideals is the man who is alive." - Cervantes|
+------------------------------------------------------------------------+
 
 
 

tcl 8.4 support

Post by Larry W. V » Sun, 19 Oct 2008 00:26:57


Here's my thoughts. Please understand... I'm just another user of Tcl.
However, I am in the process of rolling out a Tcl 8.5.4 (too late to
look at 8.5.5) environment. So far, a small sampling of developers
have tried out their Tcl 8.3 and 8.4 code with it.

What I have found is that there are varying reactions. Some people
found the change relatively painless - point to the new interpreter,
and go.

Other people saw differences (primarily in GUI applications), but they
were willing to live with the differences.

Other people saw GUI differences and wanted things to look the same as
before. Sometimes, that was simple to work around and sometimes more
difficult. In some cases, we didn't really find a complete work around
yet, but the developers were not making a concerted effort to port to
the new version - they were doing one of those "give me a reaction
after a couple of hours" types of evaluation.

Still others found they had to make other kinds of code changes. I
know, for instance, that along with the new Tcl I also provided the
current versions of a couple of dozen packages. Some of those had
interface changes, and so code had to change for that. Sometimes, this
was a tcl coding change, and sometimes it may require a bit of wrapper
code for the application, to get various environmental variables set
appropriately).

So far, there is one package which I have not been able to get to
build. So applications using that package will either stay with the
older version of Tcl, or examine the possibility of coding changes to
eliminate the dependency on that package.

The general reaction of those who took the time to try out the new
version and respond was generally positive. I know that when I looked
at all the ChangeLogs for the code used to build the environment, the
amount of improvements and bug fixes made over the last eight years is
pretty impressive.

One area that has not been addressed yet are a couple of C Tcl
extensions we have. Resources were not available to spend porting
these to Tcl 8.5 yet. That is going to be a throttle to acceptance in
the production environment, but is a resource management detail that
has to be negotiated by various projects.

I would say that the impact depends on what packages you change, and
how many releases have gone by since the last version installed. The
smaller the increment, and the more often your code is simple Tcl
scripts, the less painful the change seems to be. If you have C code
using Tcl, the pain likely depends again on how large of a jump
between the last version used and the new version you are making.

Notice that 8.5 has been around now for about 11 months. Tcl 8.4 has
been around for over 6 years! I don't know if the intent is for 8.5 to
be around QUITE that long. But I hope it does manage to stick around
for multiple years, because it is a non-trivial cost to upgrade
products and applications.

Tcl 8.6 has at least one major ''hot feature'' - co-routines. As far
as I am aware, there isn't an intention to change syntax in an
incompatible way to support co-routines.
 
 
 

tcl 8.4 support

Post by Jeff Hobb » Sun, 19 Oct 2008 07:11:09


And to follow up with ... while 8.4 will no longer be receiving active
core maintenance, if it is important in your product lifecycle,
ActiveState does and will continue to offer enterprise support for
8.4.

Jeff
 
 
 

tcl 8.4 support

Post by Donal K. F » Sun, 19 Oct 2008 18:13:05


The current "big ticket" items in 8.6 for sure (i.e. the code is
checked in, and there's already been an alpha release with them) are:
* coroutines
* TclOO

Other new features that are less sizeable:
* prefix handling command
* scripted channel transforms
* standalone pipe support
* more [lsearch] and [lsort] options
* more flexibility for ensembles

All the above should not be disruptive to third-party code as they
involve new commands in reserved namespaces or new subcommands or
options of existing commands.

Of the things that *are* potentially an issue, the key ones are:
* more const-correctness
* elimination of interp->result
There are backward-compatibility macros to help with the first, and if
your code is hit by the second then it's been running on borrowed time
since 8.0!

Donal.