I know this is a nasty question, but I still need to ask it. Is there any conclusion on when the 'final' API/Interface will be decided ? For me it's related to : http://www.gamedev.net/community/forums/topic.asp?topic_id=370222 But the point is - I think after 2 years, I'm about ready to release a version of BeatHarness to the public. The strong point of BH has always been - it's scriptable, anyone can add effects and/or transitions. If I release it, I want to know for *sure* that I won't release a version anytime soon that will need updated scripts. I want people to write their own effects and transitions, so the last thing that should happen is that once people have written their own scripts, they need to rewrite them for the next version of BH. (And for that matter, the next version of AS ;)) So the question is... Will there be a 'stable' version that will be at least backwards-compatible ? Will there be a version (and when..? 2 weeks ? 6 months ?) I can incorporate in BH, having the knowledge that whatever happens *internally* to AS, they won't have to rewrite their scripts ..? I'm really anxious to put the first 'real' version of BH out the door, but I'm really afraid that *if* people would even *like* it, and they'd start writing scripts.. the scripts would be invalid with the next release.

You need to settle on a single standard interface then. Ideally, so long as you don't change the interface you register with scripts, you can keep releasing new versions, with nothing changed from the perspective of the scripts.

Or you can support multiple angelscript versions. It should be dead simple to get two versions of AS side by side if you are loading from DLL. Somewhat more difficult otherwise. Then, the script can specify which version it wants - perhaps using a #pragma tag, which my preprocessor can parse for you.

Quote:Original post by Deyja
You need to settle on a single standard interface then. Ideally, so long as you don't change the interface you register with scripts, you can keep releasing new versions, with nothing changed from the perspective of the scripts.

Or you can support multiple angelscript versions. It should be dead simple to get two versions of AS side by side if you are loading from DLL. Somewhat more difficult otherwise. Then, the script can specify which version it wants - perhaps using a #pragma tag, which my preprocessor can parse for you.

All of this I know :)
I was referring to f.e. the way references are handled.
Scripts that were working fine for me with the previous release,
are giving errors/warnings with 2.5.

So I don't care if I need to change my code for new releases of AS..
It's about the scripts.
If one day I have a script that's working fine, and the next it's giving warnings/errors - that's one thing I don't want once I've released my program.
For gamedevelopers it shouldn't matter too much - you check the assertions, fix the scripts, and once you release the game all scripts should work fine.

But the essence of BH is that the program is released once,
and from then on other people can write scripts for it.
If someone writes 10 scripts, and they give errors with a new version of BH,
that person will probably not write any more scripts from then on - since in 5 months time all the efforts will probably be wasted.
So I want to be sure to release BH with script-support that will be either always be backward compatible - running the old scripts - or with a tool to automaticly update scripts to the new convention.

I don't want to promise a final version of AngelScript, from where I can make no modifications afterwards.

However, I have frozen a couple of versions that I promise to support with bug fixes as necessary. If you want to release a version of BH, and then not worry about invalidating scripts when releasing new versions, you should choose one of the stable versions of AngelScript and stick with that.

The latest stable version is 2.4.1d. I cannot say when I'll decide to freeze another stable version, but it will probably only be when class methods with inheritances, etc, is fully working.

This is true for any project using AngelScript. I do not promise compatibility between different versions, but I do not really see why I should have to. The interface that applications expose to the scripts are probably rarely compatible anyway, so any chance of reusing scripts between applications is remote.

I'm sure that when I've implemented all the features I want in AngelScript there will be a moment when only bug fixes and optimizations are released, but I'm not anywhere close to that level of maturity in the script language yet.

I hope you can understand my point of view.

Regards,
Andreas

PS. I think Deyja's idea of supporting different versions of AngelScript is a really good one. Have the script write which version of AngelScript they are targetting at the beginning of the file, and then choose the correct plugin for compiling the script. This would work kind of like the shader language in DirectX that have versions v1.0, v1.1, v2.0, v3.0 all working at the same time.

Quote:Original post by Rain Dog
I agree with the idea of multiple versions support.

I don't think that's a good solution..
I don't want to add a tag to my scripts specifying which version to use,
and I really wouldn't want to have to register my functions differently for each version..
By handle with this version, by reference with another version, etc..
Keeping it backward-compatible (with new versions of AS being released) would be a bitch - I'd have to add new interfaces each time :)

I'd like the users/script-writers to have one consistent way of doing things,
one version of the help-file.
(not : "If you specify version 2.4 the call takes these parameters, in version 2.5 you should specify them completely different, in version 2.7 the entire parameter-set has changed")

This is not intended as a stab at Andreas - kudos to you, without AS my project wouldn't even be alive :)

But for the time being I'll just stick to 2.4.1d :)

I understand you perfectly. Don't worry about my feelings. [wink]

I only feel sorry that I cannot attend to everybody's need.

But for the good of AngelScript I will not be bogged down by the need to keep backwards compatibility issues with each release. I try not to break compatibilities, but when I do, it's for a good reason.

By the way, I've decided to change the restriction of the &inout parameter type. For consistency's sake it will now only work for object types that support object handles. By adding this restriction script writers won't fall into the trap that you yourself did, with not all expressions being allowed as arguments.