Backwards compatibility (was Re: how can you tell you have merged?)

[Bill Barry]

Matt Mackall wrote:
> On Fri, 2008-09-12 at 00:54 +0200, Johannes Stezenbach wrote:
>   
>> If you're going to make a Mercurial-NG it could maybe
>> include a seperate machine interface (like gdb/MI) for IDEs
>> to avoid this kind of problem.
>>     
>
> That won't help. Most users will continue to take the normal output of
> hg and use it in their one-off scripts and build systems and will be
> justly frustrated if upgrading breaks things.
>   
I think a hard freeze on the API is good. I'm not quite convinced that 
it should be the default commandset. Aren't the default commands localized?

I've thought that it would be a good idea to have a secondary command 
which was always api frozen. Perhaps for every command, there would also 
be a copy of the command with an "s" applied to the beginning of it. 
Such a command would never get localization changes. The problem with 
this is that if we let the non-frozen api change, eventually it will be 
different enough that people may want to use it instead of the frozen 
version (perhaps for better information). Once that happens, the 
original goal has been lost and we get stuck with what we currently have 
(except that it would be more complex with more commands).

Maybe the best way to do it would be to version the commands. In hgrc we 
could have something like:
[alias]
status=status -V 3

would lock the status command to version 3 of the api for it. The 
problem with this is bloat. Every time the api changes, that number 
needs to be incremented and the previous api must still be made 
available. That means bigger binaries/scripts and more testing.

Of course, this is why a structured version of the api could exist which 
doesn't get frozen ever but has a specific method of data retrieval (for 
instance xml could be parsed with xpath and the same xpath expression 
could always be used to get the same data; an ini like structure 
presents the same capabilities, as does json, etc.)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://selenic.com/pipermail/mercurial/attachments/20080911/d571d25e/attachment.htm