[Bf-committers] Can we please stop breaking APIs?

Matt Ebb matt at mke3.net
Mon Jul 18 06:59:48 CEST 2011


>
> I am not trying to be difficult here, but there are cases it doesn't
> really make sense or isn't likely to even help much.
>

I agree, the situation isn't as simple as "don't change anything at all",
and to clarify, that's not what I was saying, so I'm sorry if that's how it
was interpreted. But it's also not as simple as "blender is in development
so anything is up for grabs and can change at any moment for whatever
reason". I'm also not saying that improvements, like this buffer one,
shouldn't happen - the main thing is that things don't just suddenly get
*broken*.

There are varying levels of necessity for things to change, and they need to
be treated differently, but with as much sensitivity as possible to the
peopel affected by the changes.

For example, it could be:

* Big structural refactors internal to blender: There's not much (like
deprecation) that can be done here other than give as much advance warning
as possible on mailing lists, blender release notes pages. Same with if an
operator gets changed drastically and has new properties

* Changes like this recent buffer one: Add the new method of access and
deprecate the old one for a blender release or two.

* Changes to naming or organisation for consistency or 'niceness': Perhaps
rather than change bit by bit, putit off for a while and gather a big list
with advance warning and do a whole bunch of changes simultaneously (like
what happened earlier with the big rna name reshuffle), ideally deprecating
old versions for a release or two. If just changing a couple of names,
definitely deprecate. Like you say, also good to take likelihood of usage
into account, i.e. don't rename something that's commonly used just for the
hell of it.

On Mon, Jul 18, 2011 at 1:59 PM, Campbell Barton <ideasman42 at gmail.com>wrote:

> Throughout this discussion deprecation has always been an option and
> something we agree can be used at times, my main concern is that we
> deprecate stuff and don't remove it as happened with 2.x time frame
> for removal - every second release?, whatever it is we need to be able
> to manage it but I think a year is too long.
>

I agree, 6 months (especially if the attempted 3 month release schedule can
be maintained) should be enough. The main thing is that things don't just
break immediately.

The value of deprecation is that it allows and empowers people to manage
change themselves, and manage their time spent on it. Say you're a TD in a
studio and have a bunch of custom python tools written. A new blender
version comes out, you test it for a bit, and all is well. After you've used
it for a little while you're in the middle of a project and then one of your
less-often-used tools that an artist wants to use has broken because of some
little change. This is really annoying and messes up your project
management, since it forces you to stop what you're doing and spend time on
fixing things immediately in order to continue, losing time on your job.
When stuff like this happens, no matter how 'small' the change, it's really,
really annoying.

If that change was deprecated instead, perhaps you'd get a little warning
icon in blender's reports header. Then you can say "right, I'd better change
that soon, I'll do it right after this deadline when I've got a bit more
time". It gives you the ability to manage the change yourself and fix things
on your own schedule.

I'd also like to make the point that using as much deprecation as possible
(with reporting internal to blender, in the console, reports header, etc) is
the best way to go. Announcing and warning on mailing lists like bf-python
is also great, *additionally*, but it shouldn't be a requirement of using
blender to be signed up to all these mailing lists and reading all the
discussions that happen inside. I try my best to stay as involved as
possible these days but even I have trouble keeping up with things,
especially when busy with 'real work'.

cheers

Matt


More information about the Bf-committers mailing list