I suspect I'm one of the people Ton is mentioning so I'll say a quick word here. These days at least for me, trying to work on an addon is frustrating and demotivating, and the number one cause of it is API instability.
Maybe this is just something personal to my situation because I don't have a lot of time for this sort of thing these days but for the last several months the pattern has been something like: "ah I have some time on a Sunday afternoon, why not do a few improvements and make some more progress on the addon". So I update blender, and spend all the time I have available testing and hunting through commit logs and googling just trying to make the damn thing work again, without doing any creative/productive work of my own. Next time around, it's the same pattern over and over again. So these days there's little motivation to spend my free time finishing off the remaining last round of fixes, let alone updating to fix the next. It seems somehow acceptable now that scripts have to be updated every few months, because as long as people change addons that are included in SVN then there's no problem, right? Too bad if you don't want to work that way, or have custom/proprietary tools. To answer what kind of changes cause problems, *every* change is a potential breakage and can make the difference in the eyes of a user between an addon that works and an addon that doesn't. As I've mentioned in the past, imo theres much too low a priority given to api stability. Looking at those pages previously linked (better publicity for this would probably help), there's all kinds of minor renaming that all will break a script that is using it. Having consistent names for properties can be a nice hint as an aid to API users but constantly renaming things erases all minor benefits and just makes life difficult. I was also pretty astounded previously to have to update all of the template list calls, an absolutely fundamental ui function, which apparently could not have been implemented as a separate function or optional arguments? These sorts of changes would never happen in any other app I use with a scripting API. In specific one thing that I now have to fix is a bizarre error that's never happened before, has cropped up in the last couple of months and doesn't seem to show up in other examples included in blender, like ArmatureButtonsPanel. [1] Anyway, I know this could sound quite self centred. It's really not meant to be, just a description of what a constantly changing API means to someone in my position. If more time and effort is necessary to effectively use blender's python API then I'm probably just not able to devote in the requisite amount of time and energy, and I can accept that, and probably won't much more. It's disappointing though. Hope that provided some of the background you were looking for. cheers Matt [1] https://github.com/mattebb/3delightblender/blob/master/ui.py bpy.utils.register_module(): failed to registering class <class '3delightblender.ui.InlineRibPanel'> Traceback (most recent call last): File "bin/blender.app/Contents/MacOS/2.67/scripts/modules/bpy/utils.py", line 578, in register_module register_class(cls) AttributeError: expected Panel, InlineRibPanel class to have an "draw" attribute On Mon, May 27, 2013 at 1:50 AM, Campbell Barton <ideasma...@gmail.com>wrote: > Id like to hear what API changes cause problems. > > * if its one large change that causes problems for every one using the > api (bmesh, pynodes) > * if its misc changes in blender which propagate down into the api - > (recent premul/alpha changes). > * if its from being strict and adding limits like the restricted > context, or disallowing data editing during drawing. (things that > shouldn't be done anyway). > * if its even intentional/known-about - Some end up being side effects > of other changes in blender. > > On Sun, May 26, 2013 at 10:59 PM, Ton Roosendaal <t...@blender.org> wrote: > > Hi, > > > > Excellent, we do have a API change page :) > > http://wiki.blender.org/index.php/Extensions:2.6/Py/API_Changes > > > > Should get more prominent linking everywhere! > > > > -Ton- > > > > -------------------------------------------------------- > > Ton Roosendaal - t...@blender.org - www.blender.org > > Chairman Blender Foundation - Producer Blender Institute > > Entrepotdok 57A - 1018AD Amsterdam - The Netherlands > > > > > > > > On 26 May, 2013, at 13:23, Ton Roosendaal wrote: > > > >> Hi all, > >> > >> This is probably just coincidentally, but just in past few days two > quite visible py scripters moaned in public about API breakage, more or > less mentioning to give up on it. > >> > >> Communication is really King here. That means for every release, a > simple quick to find doc with API changes has to be available (or is there > one?). > >> > >> We can also reconfirm the procedures for api changes, to go along our > release cycle: > >> > >> - Announce in BCon1 or BCon2. > >> - Add it in BCon2 latest. > >> - Testing, feedback during BCon3 and BCon4. > >> > >> We also have a bf-python mailing list where these topics are valid to > discuss. I think every API change should be a topic for review there as > well. It probably is? :) > >> > >> I think by default scripters can expect the API to keep working. > Checking back on the history of Python script breakage discussion here, it > appeared the changes were more related to "keep a good quality and sane > API". Our scripting API is also powerful, and if you find smart bypasses > for undocumented or accidentally working features, things can get > frustrated... > >> > >> If you depend on the API to keep working, please consider to join > bf-python, and help us out with reviews and design decisions! > >> > >> Thanks, > >> > >> -Ton- > >> > >> -------------------------------------------------------- > >> Ton Roosendaal - t...@blender.org - www.blender.org > >> Chairman Blender Foundation - Producer Blender Institute > >> Entrepotdok 57A - 1018AD Amsterdam - The Netherlands > >> > >> > >> > >> _______________________________________________ > >> Bf-committers mailing list > >> Bf-committers@blender.org > >> http://lists.blender.org/mailman/listinfo/bf-committers > > > > _______________________________________________ > > Bf-committers mailing list > > Bf-committers@blender.org > > http://lists.blender.org/mailman/listinfo/bf-committers > > > > -- > - Campbell > _______________________________________________ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers