 |
lua-l archive |
|
|
||
|
On 3-Sep-05, at 5:21 PM, Lisa Parratt wrote:
On 3 Sep 2005, at 21:22, Mike Pall wrote:This is documented in the manual that accompanies Lua 5.1 alpha.Read the comments for package.seeall(), too. A recent mailing list thread inspired this change:*snip*This breaking of backwards compatibility makes me very uncomfortable with deploying Lua. The cost of upgrading Lua code to work with new versions of the interpreter seems very high. It strikes me that a natural consequence of this is that people will keep their own private patched forks of Lua with their own patches, rather than incur the cost of upgrading to the current trunk, leading to fragmentation and severely reduced reusability of script code. With my software engineer hat on, this seems like a Very Bad Thing(TM)
I'm sympathetic to this argument. But there are a few important facts:1) The Lua release cycle is relatively long. 5.0 is now three years old, for example, and the historical record has been about one major release every three years.
2) If you have made significant patches to Lua, it is unlikely that you will be able to integrate them without pain into a new version, anyway. With 5.1, I will have been through this three times (although every time I find I have fewer patches which I need to integrate), and it is leading me to the conclusion that making significant patches to a scripting language may not be a Really Bright Idea unless I'm prepared to stick with a version.
3) You don't have to upgrade. There are still many products out there with Lua v4 integrated, and even some with Lua v3.2. In fact, I know of at least one with Lua v2.0 (whose author said once that he felt confident that he would be able to "maintain the Lua 2 codebase forever if need be"). That is probably true, because core Lua is written in very portable C.
4) The consequence is that Lua does not drag its old baggage with it, which is a Good Thing (sm).
The stability of the Lua codebase is exceptional. Unlike many other products, it is not necessary to upgrade to the Most Recent Patch every four weeks in order to avoid security issues.
This may be cold comfort coming on the eve of a release (relatively speaking; we're still probably several months away from a final release of 5.1). But the slowness of the release cycle combined with the extensive ( :) ) discussion on the mailing list gives a lot of opportunity and time to make an informed decision about which version to base a product on.
R.