(original) (raw)
On 07/17/2015 03:35 PM, Eric
Christopher wrote:
What I was trying to get at is that we should aim to not change the API unless it's actually \*needed\*. Just because we have a versioning mechanism doesn't mean we should freely make use of it. Some examples:
On Fri, Jul 17, 2015 at 3:33 PM Philip Reames <listmail@philipreames.com> wrote:
On 07/17/2015 12:36 PM, Juergen Ributzka wrote:
\> Hi @ll,
\>
\> a few of us had recently a discussion about how to manage the C API and possible policies regarding addition, maintenance, deprecation, and removal of API.
\>
\> Even thought there is a strong agreement in the community that we shouldn't break released C API and should be backwards compatible, there doesn’t seem to be a developer policy that backs that up. This is something we should fix.
+1
\>
\> I was wondering what the interested parties think of the current approach and what could/should we improve to make the use and maintenance of the C API easier for users and the developers alike.
\>
\> I was hoping we could also introduce a process that allows the removal of an API after it has been deprecated for a whole release and the release notes stated that it will be removed.
+1
I'd suggest we also have an officially unofficial policy about not
versioning just for style or cleanliness reasons. i.e. We should try to
minimize churn of the API unless it's actually needed, or supporting an
old API becomes unjustifiably complicated.
Could you explain what you mean here? As far as I can tell this is "I don't want versioning unless I want versioning and then I'll want it because it's convenient for me"
\- Renaming a method in the API - bad
\- Dropping a method involving functionality no longer supported - good
We tend to be much more free with the C++ APIs (with good cause). I don't want to see this applied to the C API. We should still seek to keep a stable API even if we do have a formal mechanism for revising it.
p.s. If that sounds obvious, you've read it right. :) This wasn't intended to be controversial, just to cement in writing the attitude we've already taken.
p.p.s. The preceding would only apply to the "stable" parts of the API.
Philip