> 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 making...no 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 jesse > -- > Alex Karasulu > My Blog :: http://www.jroller.com/akarasulu/ > Apache Directory Server :: http://directory.apache.org > Apache MINA :: http://mina.apache.org > >
