incubator-cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Holsman <...@holsman.net>
Subject Re: API versioning
Date Wed, 06 Jan 2010 21:41:36 GMT
Hi Eric.
can you add a new method api_version?
some people will probably still want to know the version of the software being run, and it
is still useful info to have for operational issues.

+1 on the numbering scheme. 

as for breaking something that works (ie a client library), you can make the client library
just have a 'SUPPORTED_VERSION' api call and a 'reported_version' api call, and let the application
decide.

On Jan 7, 2010, at 7:23 AM, Eric Evans wrote:

> 
> I'd like to propose a change to the way we version our API.
> 
> Currently, we publish a version string via the thrift method
> get_string_property("version"). This version string always moves in
> lock-step with the current release, i.e. 0.4.0-beta2, 0.5.0-rc3, etc.
> 
> There is no useful correlation that can be made like this. If a client
> API worked with 0.5.0-beta1, it might or might not work with
> 0.5.0-beta2. I think we can do better.
> 
> I propose that we return a string composed of joining two integers with
> a ".", where the integers represent a major and minor respectively. The
> rules for incrementing these would be simple:
> 
> 1. If it is absolutely breaking, then the major is incremented by one.
> For example, changing the number or disposition of required arguments.
> 
> 2. If it will result in an API that is backward-compatible with the
> previous version, then the minor is incremented. For example, if a new
> method is added.
> 
> This would provide client API authors the tools necessary to ensure
> compatibility at runtime, and to better manage the life-cycle of their
> projects.
> 
> What does everyone think?
> 
> 
> -- 
> Eric Evans
> eevans@rackspace.com
> 

--
Ian Holsman
Ian@Holsman.net




Mime
View raw message