Page 1 of 1
Backwards compatibility Please!
Posted: Sat Aug 09, 2003 6:26 am
Lots of times, in new updates of Blender, older python scripts stop working. But lots of (or most) other scripting languages are backwards compatible.
I think backwards compatibility is extremely important. Because of the current problems, most Blender scripts that are available on the internet won't run in 2.28. Apparently you're making some things more consistent, but after that, I hope from 2.28 (or 2.29) on, it is always backwards compatible. Please! Then people will be able to use older scripts without running an older version of Blender.
Posted: Sat Aug 09, 2003 8:14 pm
I feel your pain, dude, since I'm currently porting a script that I promised for someone at SIGGRAPH ( Hi Groo! ).
The compatibility problem comes from the historical fact that the blender's python interface was never 'finished' in the sense of providing access to all the data structures. Couple this with the fact that it was re-implemented at least a couple of times by different people with different ideas and you have the current situation.
So we have good news and bad news. The bad news is that old scripts will have to be ported. Names have changed and things like storing global data are much different. The good news is that the python team has been working with a collective vision and admirable thoroughness to build a new foundation that will carry us forward. Everyone please take a moment to stand and give them a round of applause. Nice work guys!
Blender is a young program and the python part is simply embryonic. There *will* be changes in the future, the previously mentioned global data being one of them ( Hi Willian!) However, adapting to the changes will be much less work since the basic framework being laid down is going to be more stable. Backward compatibility will become less of an issue.
In the meantime, you'll just have to bite the bullet and port. Ask questions if you get stuck. There are a lot of people willing to help.
Hmmm, maybe we should have a sticky topic in the forum for porting advice since everyone is going to bang into the same kind of problems.
Posted: Sun Aug 10, 2003 4:53 am
Posted: Sun Aug 10, 2003 1:15 pm
here's the idea that we had with regards to compatibility:
Try to be compatible as much as possible with the old version (2.23 / 2.25). In future versions, if something is going to change, then warn the user that a certain function/method is deprecated and that he should use the alternative.
For example, I've added a warning to the getSelected() function in the Object module. This function will be removed in future versions of Blender. What it tells you to use instead is the GetSelected() function.
Now with the new implementation up and running, we hope to have less compatibility problems in the future. So in the end, the user should benefit from the small transition problems you all currently have. I'm sorry.
Oh, if you indeed have some compatibility problems, you should report them either here or in the bug tracker (via the projects link at the top of this page). It could be a bug. A lot of those problems are already fixed in cvs and a new version of blender with purely bug fixes will be available soon.
Posted: Sun Aug 10, 2003 1:59 pm
....In future versions, if something is going to change, then warn the user that a certain function/method is depreciated and that he should use the alternative....
That's a good idea... but in 2.29 or so I think you should try and be committed to never breaking backwards compatibility from then on....
I mean, most scripts aren't updated by their authors. They are floating around on the internet. If someone downloads one and sees some depreciation warnings, they'd probably just ignore it - since the console isn't normally visible anyway and the script would currently work so it wouldn't be necessary to immediately edit the script... then in later versions of blender, those old functions would disappear and they wouldn't have a clue what the new names are. They could start up an earlier version of Blender to find out, but that would be too much trouble for a lot of people. Ideally, when the scripts are updated so that they run with the latest version of blender, they should replace the old scripts on the internet sites... so that people download the new versions rather than the old versions... it is easier if the old scripts just continue to run. It also means that people can keep a collection of scripts on their harddrive that will continue to work in the future... rather than them having to download updates (assuming they exist) or attempt to fix them themselves (which might be too hard for many people).
I think in future versions (after 2.29 or so) the classes should just be extended.... not modified so as to break compatibility. And if something becomes outdated (like the old non-armature bones they still have in blender) it could still be there - it could be a "legacy" thing - and there wouldn't be a need to have a warning - assuming that old things keep on being supported.
Posted: Sat Oct 19, 2013 10:49 am
Would it possible to build a virtual bridge between older and newer versions of Blender? I've seen it done in other modeling application like Caligari Truespace 7.6/6.6. Basically, a modeler can switch between 7.6 and 6.6 with software based bridge. Could it be done in Blender? Just curious about the issue. Thanks, Leroy.