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
eev...@rackspace.com
