monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] interface versions, again


From: Thomas Keller
Subject: Re: [Monotone-devel] interface versions, again
Date: Mon, 22 Dec 2008 23:15:24 +0100
User-agent: Thunderbird 2.0.0.18 (Macintosh/20081105)

Thomas Moschny schrieb:
> Thomas Keller wrote:
>> So, to make a long story short I propose that interface versions are
>> _not_ changed by individual developers up until the next release and
>> that the release manager rather takes care of the numbering, just
>> because he gets the ultimative overview what has been added / changed
>> when he writes the NEWS file.
> 
> You gave good arguments why this is the only viable way.
> 
> On the other hand, there's a downside: People using automate against a
> devel version (e.g. for testing the newly implemented features) will see
> wrong (i.e. too low) interface version.

Yes, this is correct. On the other side, the current mess with version
numbering between releases did not make checking interface versions /
capabilities useful either, so people would gain something with your
proposal which they may have been advertised to get through the plain
version numbering, but never actually received because of the
inconsistencies in the past, so they did not rely on it anyways.

> This dilemma is imho inherent to the numerical schema we currently use.
> I think I've proposed that before, but what would solve the issue is a
> keyword based interface version. So, instead of one numerical value, the
> interface version call would return a list of keywords, each of them
> specifying an sub functionality of the automate protocol, implemented by
> that server.
> 
> This way new or changed functionality can be advertised immediately and
> independently of other parts of the protocol.

I'm totally with you that it would be nice to have this, but does
somebody care enough enough to actually implement it?

Implementation could be straight foward, I think (maybe this was it even
what you proposed months ago, I'm too lazy to look for the email back
then for now ;):

We expand the CMD_AUTOMATE macro with a "token" parameter which adds the
token to a list of static tokens on runtime / initialization. This list
of tokens is then returned by another automate command. A simple rule
for backwards compatible changes would be to add `token` + `inc` to the
list, for backwards incompatible ones `token` + `inc` would be added and
`token` + (`inc` - 1) would be removed and for each new command `token`
+ 1 would be added.

Thomas.

-- 
GPG-Key 0x160D1092 | address@hidden | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]