On 1/5/11 5:27 PM, Alex Karasulu wrote:
On Wed, Jan 5, 2011 at 6:06 PM, Emmanuel Lécharny<elecha...@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
