directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <>
Subject Re: [DISCUSS] [Release Scheme] Contract/Policy with users for releases
Date Wed, 05 Jan 2011 21:18:58 GMT
On 1/5/11 9:49 PM, Alex Karasulu wrote:
> On Wed, Jan 5, 2011 at 10:06 PM, Emmanuel Lécharny<>wrote:
>> On 1/5/11 8:17 PM, Alex Karasulu wrote:
>>> On Wed, Jan 5, 2011 at 8:13 PM, Emmanuel Lecharny<
>>>> wrote:
>>>   On 1/5/11 6:49 PM, Alex Karasulu wrote:
>>>> So when considering compatibility we have to consider several things
>>>>> besides
>>>>> just APIs and SPIs:
>>>>>    o Database Format
>>>>>    o Schema
>>>>>    o Replication Mechanism
>>>>>    o Configuration
>>>>>    o API Compatibility
>>>>>    o Plugins - We have pseudo plugins like Partitions, Interceptors and
>>>>> Handlers that users can alter which involve SPIs.
>>>>>   I would get the Database Format and Configuration out of the equation.
>>>> It's
>>>> up to us to provide tools to migrate from one format to the other. Don't
>>>> get
>>>> me wrong : when I say that configuration is out of the equation, I mean
>>>> that
>>>> the configuration can change, not its format (ie switching from XML to
>>>> DIT
>>>> is possible between to major releases, not between two minor releases).
>>>>   Will this be transparent to the user? Meaning can he just upgrade the
>>> software and the migration will occur without any change in their
>>> workflow,
>>> or anything noticeable in performance, wait time on startup? More
>>> specifically:
>>> (1) Does the user have to run a tool to migrate from one version to the
>>> next
>>> ?
>> Definitively, yes.
> This is a bit worrisome to me but I cannot figure out why yet. Something in
> my gut that I have not translated into real consequences yet.
> I can see advantages with such a tool which allows us to change these
> formats and configurations. But the disadvantage is the one off of having to
> figure out if you need the tool with every minor or micro release. It's yet
> another one off and the tool make take a day to run depending on how big the
> DIB is.

We are not likely to change those DB formats often. We did it 3 times in 
6 years, and it was for some major refactoring, I can't foresee any 
small modification that could be needed soon.

However, I do think that at some point, this might be necessary to ofter 
such a tool. It's too easy to rely on our user to get their data 
exported and reimported using a LDIF file, as it has some consequence : 
the operational attributes will be modified.

> However with modularity and OSGi these points become less problematic.
> If this is set as the policy then this tool must always be provided. Those
> who push this as the way then need to be held responsible for providing the
> tool when needed. That sort of goes against the community dynamic: it's
> going to be a must do for those accepting the policy.
Same opinion here.
> So for those who want it, it should be provided by them on demand before any
> release takes place. That's kind of harsh.
> Instead if we respect the DB format and just release with the right
> versioning schemes then we should be OK. If compatibility breaks then a
> major release can be done and tools can still be provided to migrate
> optionally without requirement.
> See my point here?
yes. But again, such a modification is not likely to happen, is not part 
of the contract, and can be manage if we provide a migration tool. It's 
quite a common practice in the industry, and should not be a burden. It 
should even not require a major release, IMO.
>   (2) If a user has 100 Million entries and there's a migration operation
>>> running with this take say a few hours to start up the server?
>> This should be a low level tool, so it should act on the Backend interface
>> level
> Yeah but it can still take days depending on the DB size but should not be
> an issue with 90% of our users.
The day we have a user with 100 million entries, trust me, we will have 
other issues than just dealing with the migration of its database :)

Emmanuel Lécharny

View raw message