Hi - here are my thoughts on compatibility: Breaking compatibility at the TCL level is worse than breaking it at the C level. If someone wants to write a new, incompatible version of ns_return for example, it should be called something else and a compatibility wrapper written for ns_return that calls the new thing. In the best case, TCL compatibility should NEVER be broken. If we end up with a huge compatbility library, perhaps all written in TCL, that's much preferable to telling people to change their code.
Breaking compatibility at the C level is more acceptable to me, because my guess is that very few people are using it. We have a small handful of C modules, so yeah, we may have to change them if the C API changes, but it would not be a big deal. Even if incompatible changes are allowed at major versions, what may very well happen is that it fractures the community and leaves some people running old versions longer than they want. We're in this situation now because of ns_shares: someone decided it was inconvenient to provide ns_share because of TCL core modifications, which I totally understand. But, we have a code base with over 800 ns_share statements, and probably 5x that many variable references. It will be a cold day in Hell before we rewrite all our code to use nsv arrays, just because someone decided that ns_shares are inconvenient to support. If ns_share ever goes away completely, we won't be upgrading, no matter how great a new version is. The other paradox with good, reliable software is that people don't have as much of a pressing need to upgrade it. So while a development group is releasing version after version of a product, and may have even released several production versions, there will be many customers that have not even tried the new version. Eventually, there will be a pressing need that forces the customer to consider upgrading. The Linux OS is an example of this, for us. We didn't upgrade to 2.4 until November of 2003, even though 2.4 had been released for a long time, because 2.2 was working fine for our needs. The 2 things that forced us to upgrade were that we needed to access more main memory, and our storage requirements increased to the point that we couldn't afford to do fsck's and needed a journaling file system. My point is, production customers may be running old versions much longer than developers think. If a customer has been happily running 3.4 AS for a few years and a compelling reason comes along for them to upgrade, and the current version of AS is 6.5, they don't want to run into a big incompatibility hurdle. If they run into too big of a hurdle, they will likely start considering all options, including moving to a different platform that they perceive is more stable from a compatibility point of view. Jim > > Zoran implemented some recent changes to TclX keyed lists in CVS HEAD > which changed the C API, which broke at least some code at AOL which was > still using the old C API. > > Rather than a wholesale back-out of the changes, I'd like to discuss two > things: > > 1) Should changes that break backwards compatibility be allowed between > minor revisions (i.e., 4.0 -> 4.1) or should they be limited to major > releases only (i.e., 4.x -> 5.x). > > 2) Can we quickly implement some backwards compatibility for the TclX > keyed list C API so that existing C code won't need to be > modified/updated to use Zoran's new C API? What's the best way to do > this? Can it be done through #define's? Or thin wrapper C procs > that call the new C procs? Or, can we simply rename Zoran's new C > procs to the old names to preserve compatibility? > > -- Dossy > > -- > Dossy Shiobara mail: [EMAIL PROTECTED] > Panoptic Computer Network web: http://www.panoptic.com/ > "He realized the fastest way to change is to laugh at your own > folly -- then you can let go and quickly move on." (p. 70) > > > -- > AOLserver - http://www.aolserver.com/ > > To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with > the > body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field > of your email blank. > -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
