On 24/09/2013 9:50 AM, Ryan Kelly wrote:
> Forwarding input from JR, since this discussion seems to be spanning two
> different mailing lists.
I heartily endorse all of JRs comments here, with one tweak.
> Your version is:
>
> Major.Minor.Build
>
> Major - Introduces at least one non-backwards compatible function that
> will break clients. This is non-negotiable. There are no "small"
> changes. Since your unit tests are based on your published API (they
> are, right?) if they break, you change your Major.
>
> Minor - Introduces at least one new feature or function that adds to the
> existing API.
>
> Build - Fixes a bug to bring existing elements more inline with
> published specifications.
>
> The URL value contains only the Major version. Why? Because if you add a
> new feature, you're not breaking anything. If the feature didn't exist
> before, then older clients will never have called it. If you are
> breaking something, you're using a new Version.
In our world of open-source federated services, there's no guarantee
that that the particular server you're talking to is running the latest
version of the code. We have to worry about "older servers" and well as
"older clients".
For this reason I advocate vMAJOR.MINOR in the URL to reduce the chance
of a silent version expectation mismatch.
It is kinda ugly though, so two alternatives:
* Don't do minor version revs. Any non-bugfix change bumps the major
version number, and we try hard to keep these infrequent.
* Very carefully write your clients so they can take advantage of any
changes introduced in a minor version, but will operate correctly
against older servers.
Cheers,
Ryan
_______________________________________________
Sync-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/sync-dev
