transitioning release management

[simo]

On Wed, 2008-02-27 at 19:16 -0500, Derrell Lipman wrote:
> On Wed, Feb 27, 2008 at 4:32 PM, simo <idra at samba.org> wrote:
> >
> >  On Wed, 2008-02-27 at 14:19 -0500, Derrell Lipman wrote:
> >  > On Wed, Feb 27, 2008 at 2:15 PM, Volker Lendecke
> >  > <Volker.Lendecke at sernet.de> wrote:
> >  > >  What would your extensible API look like?
> >  >
> >  > The big change is that instead of the user manipulating structure
> >  > members in the context structure, the context structure will become
> >  > entirely opaque, and setter and getter functions will be used for
> >  > changing it.  This allows me to make changes to the internal context
> >  > structure, typically for adding new functionality, without affecting
> >  > the ABI.  While I'm at it, I'll clean up the use of the different
> >  > types of option settings (there are currently three different
> >  > mechanisms in use!) and the authentication callback function.
> >
> >  This sounds reasonable, but to be honest I'd like to gain something from
> >  breaking API/ABI. Breaking API/ABI means distributions may need to carry
> >  on a libsmbclient-compat package, so it's better if the difference
> >  between the 2 is because of functionality change and not just interface.
> 
> Well as I said before, it's now or never.  There's never a "good" time
> to break API/ABI compatibility, but bumping a major version (3.0 ->
> 3.2) is about the "best" time there is.
> 
> Yes, right this minute it's only an API change, but the intention is
> that functionality will be improved as time goes on.  Right now, I'm
> reluctant to add new functions and features to the library because the
> code gets messier and messier each time.  For example, function
> pointers to related functions are no longer grouped together as they
> should be for readability, in the interest of ABI consistency.  We
> currently have two authentication function signatures with a third
> possibly pending.  That's just ridiculous.  There are three different
> methods of setting options, depending upon the option.  I really don't
> want to add the non-POSIX functions that are being requested, with the
> current implementation.  It's really time for a clean up.  You're
> right, though, it is going to be a bit of a pain for the distros,
> which is why I raised the question.  Since you represent one of the
> distros, I'm particularly interested in your opinion now that you've
> heard a bit more.

Derrell,
my fear is that not adding the functionality you make a huge bet on the
fact you'll get the API/ABI right.
If you find out the new API/ABI does not fit future functionality you
will have to break it again. And that would not be painless.

How confident are you that you will get it right ?

I agree that a major release is a perfect time to do an API change, but
we are planning also to release by April and there are a tons of things
to test already. This also weighs in in making me nervous of doing this
change right now.

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo at samba.org>
Senior Software Engineer at Red Hat Inc. <ssorce at redhat.com>