<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix">On 07/17/2015 03:35 PM, Eric
Christopher wrote:<br>
</div>
<blockquote
cite="mid:CALehDX5HLZ4ir44f4a7oKZj1_npq=Z-76O0YYKudScnvxxgLAA@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
<br>
<div class="gmail_quote">
<div dir="ltr">On Fri, Jul 17, 2015 at 3:33 PM Philip Reames
<<a moz-do-not-send="true"
href="mailto:listmail@philipreames.com">listmail@philipreames.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
On 07/17/2015 12:36 PM, Juergen Ributzka wrote:<br>
> Hi @ll,<br>
><br>
> 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.<br>
><br>
> 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.<br>
+1<br>
><br>
> 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.<br>
><br>
> 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.<br>
+1<br>
<br>
I'd suggest we also have an officially unofficial policy
about not<br>
versioning just for style or cleanliness reasons. i.e. We
should try to<br>
minimize churn of the API unless it's actually needed, or
supporting an<br>
old API becomes unjustifiably complicated.<br>
<br>
</blockquote>
<div><br>
</div>
<div>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"</div>
</div>
</div>
</blockquote>
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:<br>
- Renaming a method in the API - bad<br>
- Dropping a method involving functionality no longer supported -
good<br>
<br>
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.<br>
<br>
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. <br>
<br>
p.p.s. The preceding would only apply to the "stable" parts of the
API. <br>
<br>
Philip<br>
<br>
</body>
</html>