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

[Campbell Barton]

@Matt, read you're mail and agree with you're suggestions on
deprecation, but for this to work we need some better way to notify of
deprecated api usage.
it worries me a bit that mac and win users (even script devs) don't
use the console so much anymore, of course they should not have to...
but for the moment deprecation warnings are just prints, so its
something we need to address.

@Douglas, thought about how to make sure we remove deprecated api's eventually.
For me, the easiest way to do this is to have a comment: /* DEPRECATED
YYYY/MM/D */
Then have python script which finds all deprecations and alerts if
there are any that need removing, I'll hook this up to a target in
GNUMakefile, so we can simply do "make test_deprecated".

We don't deprecate stuff often so should be easy to follow.

On Mon, Jul 18, 2011 at 4:43 PM, Knapp <magick.crow at gmail.com> wrote:
> I have 2 suggestions.
>
>> 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
>
> Why not have a Blender changes (only) email list serve that
> programmers can join. It will only tell them about changes that they
> need to know about. I would suggest that it has additions, upgrades,
> and changes in it. Perhaps ads about new blender products would be
> good here too, ones that might help the users/programmers? And perhaps
> new scripts? It should be low volume and easy to keep up with. It is
> not a place to discuss these things, it not Blender news. (starting to
> sound like a new thread)
>
>>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.
>>--Campbell
>
> If I understand you correctly changes get made and then the deprecated
> things are not removed because someone forgot to do it. If this is
> correct then why not make a Google calender with reminders. The
> reminder can be sent 6 months later to the dev list saying, "Remove
> XXXX in file YYYYY today!" That should make sure it is not forgotten
> and is easy to set up and easy to do and cost little in terms of time.
> Only devs with the authority get to enter these reminders or?
>
> IMO
>
> "API, an abbreviation of application program interface, is a set of
> routines, protocols, and tools for building software applications. A
> good API makes it easier to develop a program by providing all the
> building blocks. A programmer then puts the blocks together.
>
> Most operating environments, such as MS-Windows, provide an API so
> that programmers can write applications consistent with the operating
> environment. Although APIs are designed for programmers, they are
> ultimately good for users because they guarantee that all programs
> using a common API will have similar interfaces. This makes it easier
> for users to learn new programs."  Webopidia
>
> To me an API is a social contract between the devs and the
> programmers. It helps keep the programmers view of the package stable
> so that they can work with Blender without problems. On the other side
> of the API wall the devs have the freedom to change things without
> messing up the programmers. Any change to the API that is not liked by
> both sides is breaking the social contract and breed strife. The worst
> changes are hidden pointless ones that are undocumented; changing
> Christmas to Xmas for example. A good API should be as stable as
> possible; that is its job. Changes to it should happen in a known,
> controlled and regular fashion.
>
>
> --
> Douglas E Knapp
>
> Creative Commons Film Group, Helping people make open source movies
> with open source software!
> http://douglas.bespin.org/CommonsFilmGroup/phpBB3/index.php
>
> Massage in Gelsenkirchen-Buer:
> http://douglas.bespin.org/tcm/ztab1.htm
> Please link to me and trade links with me!
>
> Open Source Sci-Fi mmoRPG Game project.
> http://sf-journey-creations.wikispot.org/Front_Page
> http://code.google.com/p/perspectiveproject/
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
- Campbell