I'd rather not if it can be avoided. Keeping backwards compatibility for every little change pollutes the code, which is something that I try to keep at a minimum. Not only does it pollute the code but it also adds additional risks for bugs in the library.
Do you have cases of failures without this? Wouldn't it be possible to have the scripts updated (after all it is just a matter of removing the word private from the property declaration)?
AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game
I wouldn't bother you if the scripts could be updated :)
We have use-cases where we want to be able to update the engine to have the latest and greatest features/performance/etc., but our application has to be able to run existing scripts which cannot be changed.
I understand your concern - maintaining backwards compatibility for any stretch of time is a huge pain. I'll investigate a local patch. Thank you.
How do you plan on knowing how to set the engine property in case I do add this option?
AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game
I'd have to set it to 'warn' - precisely because there are lots of existing scripts and it wouldn't be feasible for me to 1) run every single codepath of every single script or 2) verify correctness by code inspection.
If it just warns but then continue to work as before, then you're missing out on the fix, aren't you?
By the way, what is this application of yours that have lots of existing scripts? I apologize if you've already told me before, I can't keep track of who is developing what 
AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game
Yes I would be missing out on that fix, but without the option to miss out on it, I wouldn't be able to update the library past that revision and I'd miss out on everything else.
I can imagine a situation where say some game company creates a game that allows users to mod some things via AngelScript. Let's say there's a community of such mods (scripts) out there. Then the game releases an update and for whatever reason (i.e. needed a bug fix) it incorporated a new AngelScript version. If there was a backwards compatibility break, that would mean that users who updated to the new version of the game would not be able to use any of the already-existing mods/scripts.. as those scripts would fail to compile.
Maybe starting with a future version (3?) you could commit to supporting backwards compatibility within that major version - that is, any valid script that was created/tested against a version 3 AS would continue to work as long as the application upgraded AS within version 3. Once the application upgraded past version 3 (say to 4), all bets are off. This is how Unity works, for example.
Just a thought.
The day I commit to 100% backwards compatibility with new versions is the day that I stop evolving the script engine and only do bug fixes. Even so, a bug fix in the compiler might also break something that was apparently working before. I avoid as much as possible making design changes that break backwards compatibility, but I really don't see how to guaranteeing that a bug fix doesn't accidentally break something.
Still, you win on the argument on the private members because it is officially documented that they are visible to derived classes. Only because of this will I add an engine property to allow the previous behaviour to be used for those applications that want it (even though it is wrong).
AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game
One easy-ish solution is to add the "protected" keyword, which is the old behavior. Then people upgrading can just run a replace-all ["private:" with "protected:"] and continue on their way. Or you could introduce a new keyword for the new behavior, "really-truly-private:" leaving the old keyword for the old behavior. "internal:" maybe. But better to be consistent with terminology used in other languages, if possible. But at some point, there will always be source-breaking changes.
(I'm not yet an angelscript user, but I read the angelscript threads in this forum alot)
Then people upgrading can just run a replace-all ["private:" with "protected:"]
The kind of backwards compatibility I'm talking about means you can't touch previously-written scripts - they have to continue working under the new AS version. If you've got a script which is under development or you're talking about future scripts, of course you'd use the improved/correct syntax :)
