directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse McConnell <>
Subject Re: [ApacheDS] How about yet another versioning scheme conversation gang?
Date Tue, 11 Aug 2009 15:26:05 GMT
> 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.

you may want to move faster but I would personally not be keen on
working with a system that didn't make the attempt to maintain api
compat with the velocity of changes you appear to be keen on one wants to subscribe to a development track where every
2.x change is going to require an unknown amount of time invested in
tweaking to align with a new API.

If your plotting those sorts of changes then the thing to do is
develop a public API that you commit to adhering to for the life of
that branch and then you can change things behind that to your hearts
content.  But give people some semblance of stability if they plan to
incorporate ads into their systems.

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

You can have rapid progression easily enough, adding all the features
you want, it simply must be additive for 2.x releases..shoot jetty has
added countless features in 6.1.[1 through 19] releases...but the api
has remained solid.  We have been kicking around going to 6.2 but we
missed the spots in the past with lots of features at once and now
with 7 (and a complete packaging change and some api breaks) going
final soon it doesn't make much sense to go back and do a 6.2 as much.

anyway, say I want to incorporate ADS into a stack, you can not
reasonably expect me to make that commitment if your going to require
me to tell my users that 'oh, I updated ADS versions for this release
and all your old data needs to be reloaded. good luck!'  That would be
kinda nasty.

Personally there are some uses that I couldn't care less about that
for, like continuum build histories....not a terrible thing to lose in
my opinion if it comes to it...but all your user information? that is
a different deal..

in summary, public api is important, two key ones being the api for
embedding ads and the data store underneath, keep those two solid and
probably in good shape :)

all in my opinion of course

> --
> Alex Karasulu
> My Blog ::
> Apache Directory Server ::
> Apache MINA ::

View raw message