directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@apache.org>
Subject Re: [ApacheDS] How about yet another versioning scheme conversation gang?
Date Tue, 11 Aug 2009 18:33:14 GMT
Alex Karasulu wrote:
> On Tue, Aug 11, 2009 at 5:17 PM, Emmanuel Lecharny <elecharny@apache.org>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



Mime
View raw message