+1, the release version is only tenously related to the API version
and tracking the latter separately would be much more useful to
clients for the reasons you gave.
One question: do we need a 3-tuple?
The 0.5 api is a superset of the 0.4 one in method names and
arguments, but the exceptions declared are different, so client code
in compiled languages with checked exceptions (only Java?) probably
needed some light editing to upgrade.
I'm also happy to just ignore that until someone actually complains though. :)
-Jonathan
On Wed, Jan 6, 2010 at 2:23 PM, Eric Evans <eev...@rackspace.com> 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
> eev...@rackspace.com
>
>
