directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: ADS 2.0 : what, how and when?
Date Wed, 05 Jan 2011 16:27:54 GMT
On Wed, Jan 5, 2011 at 6:06 PM, Emmanuel L├ęcharny <>wrote:

SNIP ...

Yeah this is my main worry. Let me though put this discussion out into
>> another thread or two for better clarity and tracking.
> We must distinguish between the LdapAPI (ie, merge of shared and Client
> API) and the server API (ie core-api plus the base classes in shared :
> entry, etc).
> I'm less worried about the Server API than I'm for the LdapAPI.
> Also I'd like to quote you on that aspect, because I find your post
> sensible (
> :
> "Also I remember a great email conversation almost 7 years ago on another
> project's mailing list. It was agreed that releasing fast and releasing
> often was more important than making sure the code was absolutely stable.
> Firstly because you can never really be absolutely stable and second because
> only life in the wild will show if the code is fit enough: fixing sometimes
> what you think is the big issue does not really fix the big problems in the
> wild. *Third and most important was the idea that stability is not that
> important. Yeah you heard me right.* Just get the feature out and let the
> user community report the problems so you can fix it fast but fix it fast
> and release fast. This keeps the user community more involved with the
> project and communicating with us. It's actually the best way to keep a
> vibrant community and spend less time testing/improving something which you
> really cannot tell is broken. You only know in the wild. I'm not saying
> write and release buggy software and nor were these guys saying this. I'm
> saying let's fear not providing stability on the first major release. If we
> blindly stick to the release early release often strategy and communicate
> with our users, then eventually we will converge towards stability with the
> least testing effort and the greatest gain in community. So let's make sure
> we get the releases out fast to fix the issues that arise for our users when
> they contact us with problems. This way we can stimulate a more vibrant user
> community while allowing us to focus more time in the right places
> developing rather than testing."
These comments are feature related. If we add a new feature get it out fast.
This argument position is not the same when it comes to managing an API. We
cannot as you know just change the API at whim.


API stability and our contract with our users if adhered to then go ahead
and release even if the implementation is not stable to get user feedback as
early as possible.

No with respect to your example we were dealing with an unstable product and
in the 1.5 branch we clearly stated this to users. "Don't depend on the API
here to be stable." It will change because we're shifting the architecture
as we are aggressively adding features to this beast. We just don't know how
this will impact the API and structures so we cannot commit ourselves to a
stable API.

Plus we knew we did not want to deal with the overhead of maintaining this
contract with users and being handcuffed to a locked API that would slow
down aggressive feature addition in a *VERY* young product.

As long as we're up front with users from the get go we're safe. But if we
say, this is a stable release with a stable API we better adhere to it.
That's why we have to have these conversations. But maybe we just don't make
these promises and just push 2.0 out letting the users know things might
shift in 2.1. Basically saying don't expect back compatibility across minor
version releases. We can set this policy that's up to us.

That does not mean we should disregard the Server API stability. We must do
> it, even if it postpone the 2.0 release for a few weeks.
> We all agree that the "release often" mantra is a good one, but I don't
> think it applies well with the version scheme we are using. However, we
> decided to follow this versioning scheme, even if it sounds like a dead body
> we are carrying, and I think it's better delaying a long expected release
> for a few more weeks rather than delivering an intermediary version and to
> release a major version a few weeks later. It sounds not consistent to me.
What I am saying is we need a discussion around what our options are here
and together determine the tradeoffs while being absolutely clear and
consistent with users of server APIs, SPIs as well as the client and shared

We do have options that can get 2.0 out the door faster and there's nothing
wrong with selecting them so long as we are open and consistent.

Alex Karasulu
My Blog ::
Apache Directory Server ::
Apache MINA ::
To set up a meeting with me:

View raw message