A stable and backwards compatible API (and file format) is very important. Imagine if the C standard kept breaking its backwards compatibility every year?
I think you owe it to your users to keep the API stable backwards compatible until a major version update (2 -> 3 -> 4, that's why Blender 2.5 should be called 3.0). My 2 cents, Erwin On Jul 17, 2011, at 6:00 AM, Nathaniel Lane <[email protected]> wrote: > I must say I agree with this completely. While I understand the need to make > some occasional changes, on the whole it seems to be bad practice to change > it as much as it has been recently. > > On Jul 17, 2011, at 5:04 AM, Matt Ebb <[email protected]> wrote: > >> I have a few things to say on this topic... >> >> >> On Sat, Jul 16, 2011 at 8:37 AM, Campbell Barton <[email protected]>wrote: >> >>> On Fri, Jul 15, 2011 at 10:35 PM, Diego B <[email protected]> wrote: >>>>> Nope, the api is not stable and probably wont be until blender >>>>> development ceases. >>>> >>>> so.. that mean that the api never will be stable ? because blender is >>>> always in development, like >>>> any other software. >>> >>> In practice we end up stabilizing most areas and don't just break >>> stuff indefinitely - But bigger changes mean api breakage is >>> unavoidable in most cases - BMesh, Particle Rewrite, Curves/Nurbs >>> branch... etc. >>> >> >> I don't think it follows that because blender is always in development (like >> any other software) that anything is up for grabs and users can never expect >> to be able to rely on a stable API. I think most people can understand that >> if a major part of the software changes internally, then the API may have to >> change as well, and with a managed path of warning and deprecation, the pain >> of transitioning can be managed. >> >> But this is not the sort of problem that is in question here - some of these >> changes, which I thought would stop after the 'stable' 2.5 release, are >> smaller, syntactic changes. They're not due to any major internal >> reorganisations, they're not part of fixing design problems, they're little >> things that really aren't that *necessary*. >> >> Like the previous change that affected me (which I only found out about when >> things stopped working), it was moving ExportHelper from io_utils to >> bpy_extras.io_utils. That was something that has nothing to do with >> reflecting changes internally in blender, it was a somewhat arbitrary >> decision to make things 'nicer' or more organised. >> >>> From the point of view of a developer who's involved in blender, who reads >> every commit log, who hangs out in IRC, who knows exactly what's happening >> in the API, this may not seem like a big deal, but for other developers >> outside that circle, or users who just want to their tools to work when they >> download a new blender, it's a huge difference - it's the difference between >> something working or not working at all - there are no varying degrees of >> difficulty here. >> >> Trying to make the api syntactically nice is not a bad goal on its own, but >> it *is* a problem when it conflicts with the API's usability. And that >> usability is not just about how much you have to type, or if the names are >> good syntactically, it's about how much trouble it is to actually develop >> tools with it and get work done. Having an unstable API that can change for >> seemingly small and arbitrary reasons really damages the API's usability >> much more than less-than-beautiful syntax or organisation does. >> >> So the legitimate need for having things well organised and with nice syntax >> and naming has to be balanced with having a usable, stable API. In some >> cases (like the one I brought up, IMO) the solution should be to just sigh, >> and live with something that's not 100% perfect, because fixing it causes a >> greater problem than it solves. In other cases, this can be handled with >> deprecation, warnings, grace periods to allow people to transition. >> >> Agree we should deprecate in some cases - at the moment its arbitrary >>> when to do so. Currently I just check if any addons/scripts use it and >>> if its documented. >>> If not, this is a reasonable indication its not widely used. (nobody >>> complained when convert_to_pyobject() was renamed for eg.) >>> >> >> This is absolutely not a reasonably indication. The fact is you really don't >> know at all who is using this stuff out there. I've done a reasonable amount >> with the 2.5 API now - not extensive by any means, but none of my stuff is >> included in addons. >> >> The benefit of having a python API is that you don't need to spend time >> being involved in IRC, mailing lists, etc in order to get work done >> developing tools. Scripters and TDs can just write stuff in python and never >> show a single other soul, or keep it for their studio to use internally, or >> distribute it themselves on the net, or give it to a client who has hired >> said coder to make a python tool. The API is not just to enable blender >> developers to make included blender tools or addons in python, there's a >> much, much wider world outside that sphere. So anything that can improve >> interaction and communication that doesn't involve being deeply involved in >> blender dev (eg. prior warnings in documentation, deprecation messages, >> grace periods, etc) is very much appreciated. >> >> Anyway, I really appreciate the work that's being done in the API, and it is >> miles ahead of what we had before. I just don't want to see baby thrown out >> with the bathwater, having a API that can be considered nice at a given >> moment in time, but is a total pain to use for real work because it's >> constantly breaking. >> >> cheers >> >> Matt >> _______________________________________________ >> Bf-committers mailing list >> [email protected] >> http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
