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).
Yeah this is my main worry. Let me though put this discussion out into
another thread or two for better clarity and tracking.
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 (http://email@example.com/msg28128.html) :
"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 libs.
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.