> > 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 <ideasma...@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 _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers