directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <elecha...@apache.org>
Subject Re: ADS 2.0 : what, how and when?
Date Wed, 05 Jan 2011 17:14:58 GMT
On 1/5/11 5:27 PM, Alex Karasulu wrote:
> On Wed, Jan 5, 2011 at 6:06 PM, Emmanuel Lécharny<elecharny@apache.org>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 (
>> http://www.mail-archive.com/dev@directory.apache.org/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.
Agreed.

But the last part of your mail was an open question about the main point 
: API stability :

"BTW my only worry with this scheme of major.minor.micro is what if we 
find a bug that requires extensive changes to the code that breaks with 
back compatibility? I have not figured out how the release scheme can 
manage this. Thoughts?
Is it suitable to bump to the next major release number if back 
compatibility needs to be broken?"

If we decide to go to a 2.0, and if we find some area in the API which 
is not stable enough (accordingly to our high ranking), then the answer 
is still pending : should we go for a 3.0 or what else ?

The *big* difference with a server like Httpd is that we do have a 
contract on the API for the schema and the messages, but we don't have 
any contact for the LDAP elements : there is no such RFC.

So it's complicated to decide when we are stable enough...

IMO, if we have to change some of the API between a RC1 and a RC2, and 
*if* and only *if* our beta-testers/users are *aware* of that, to the 
extend we don't heavily refactor those API of course, then we may accept 
the idea of small refactorings.

And even then, once 2.0-GA is out, and we find a big inconsistency in 
the API, then I do think that going for a minor (ie 2.1) is also 
acceptable, as far as we provide a guide book to help them migrating.
> Corollary:
>
> 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.
We all agreed that 1.5 was a mistake, as it was done for another purpose 
: bumping up from Java 4 to Java 5, and make it clear for the users, as 
Tomcat did with 5.5.

Sadly, we also decided that 1.5 would be "unstable" ie API could change.

Now, we are stuck with this, and we have to deal with it.
> 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.
Sure. But regarding the API, as it has been worked out for *years* now 
(the entry refactoring was done back in 2007, AFAICR (time flies) !

And nothing should forbid us to maintain a 2.0 branch while we are 
working on a 3.0 (or a 2.1)

> 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.

Absolutely ! And trust me, I'd rather have *one* single API to deal 
with, it's already an hassle to deal with.

I'm used to maintain both MINA 2.0 and MINA 1.1 APIs, and having to ask 
everytime "which version are you using" is just a plain PITA...


> 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.
I'm totally on the same page here.


> 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.
I'll be clear here : I don't want to deal with two versions of the API 
(being it server or client), it's too much trouble. I'm totally open 
minded, and welcome a discussion about those points.

There are though some elements that we never clearly decided, and you 
named it :
- is a 2.0 followed by a 2.1 allows a modification of the API or not ?
- should we consider that in X.Y.Z, the X should be incremented more 
frequently, ie should we follow the Httpd scheme for versions (one major 
every 5 years), of the ActiveMQ scheme (one major every year) ?

ADS is an elephant, and we won't be able to release many times, I think. 
We should do our best to get stable releases out of the door, and minor 
versions should be, as much as possible, feature additions release only. 
I understand your reluctance to get 2.0 out too fast, and I share this. 
However, and call it an excessive and blind confidence in the work we 
put in  the server in the last 3 years, but I 'feel' that we are quite 
safe, minus some added effort we have to put to be sure that the API is 
stable enough.

Last, not least : those who don't fell worried before a release have 
never ever worked on a project going into production ! :)

It recalls me Sarah Bernhardt being asked by a young artist if she felt 
any stress before going on stage, because she wasn't. She replied 
"Stress comes with talent" :)

-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com


Mime
View raw message