transitioning release management

[Derrell Lipman]

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.

Cheers,

Derrell