On Tue, Aug 11, 2009 at 5:17 PM, Emmanuel Lecharny <firstname.lastname@example.org>
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?
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.
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.
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.
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.