Alex Karasulu wrote:
On Tue, Aug 11, 2009 at 5:17 PM, Emmanuel Lecharny <[email protected]>wrote:
Alex Karasulu wrote:
I think we're on the same page. But I would add one more caveat, that Y
"tries" to maintain API compatibility but there is no guarantee.
Why can't we guarantee that if the API is changed, then the old API will
still be available, but marked as @deprecated, until the next X release ? Is
it too strong a constraint?
Yeah I think it is too much. Not feeling too generous on the API front
since it's going to see lots of flux. Don't want our hands tied like it was
during all these 1.0/1.5 branches. I want to move faster. The faster we
move we can come back in like 3.0 and say Y can guarantee API backwards
compatibility.
Then the question is if ADS 2.0 will be considered as a stable or
unstable version. If we have to wait for 3.0 in order to guarantee the
API stability, we are putting the users in jeopardy, but much more
important, we are creating a costly task for those of us who are dealing
with maintenance.
IMHO, we don't have a hell lot of API and that should be stable soon.
Regarding the configuration and the data, offering tools to upgrade
should be enough.
And whatever mistakes we did before should not be a reason for not
considering Jesse proposal, which make a lot of sense to me.
There is also an aspect which is not related to the API : configuration
_and_ data. For Minor versions, we must guarantee a compatible
configuration, and a compatible dataBase, otherwise we -at least- must
provide teh tooling to migrate easily both of them.
Thoughts ?
I'm not willing to guarantee this. Technically the database format and the
configuration format/scheme is yet another interface the user is faced with
regarding ADS. When I say interface I mean it very broadly to include data
formats and things like configuration.
So we have to go with tooling - which we have, as we can load all the
server.xml version since 1.5.2 in studio. Converting back and forth is
not that complicated.
Data conversion is a piece of cake : export LDIF, import LDIF.
I might want to slowly migrate some configuration feature that was in the
XML format slowly over two feature releases into ADS. If I must provide
this guarantee then I have to wait until 3.0 to introduce these changes.
It's not a good thing for us who really want to provide the user with what
they really need in the end as soon as possible.
The core configuration is likely to stabilize soon. I really don't like
the idea of having a moving target, until 3.0. We must provide some kind
of stability or ease of use during the migrations. My vote would go
toward the second aspect (more tooling).
We must allow for rapid progression. Like I said I will be willing to make
the guarantee once we're in a 3.0 or 4.0. But not now. Life is hard enough
for us already. Let's keep the load light and help users when and if there
really are API issues in the end. But it's safer to say we provide no
guarantee than to say that we do guarantee back compat.
I don't want to be stuck on the users ML for months explaining how to
migrate from version 2.0 to 2.1, if we are to release a minor every 2/3
months. The effort to put to get the migration tools is not exceeding
the time lost - and the potential users lost - in 'helping users' to
migrate.
Every time we got a mail from someone wanted to migrate from a version
1.5.X to 1.5.X+1, it was time consuming, painful, and at the end, the
user was pissed off. I don't want this scheme to be reproduced.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
