I think the v is unnecessary, but don't feel that strongly about it. What has worked for us is MAJOR.MINOR versions. This lets you communicate small, backwards-compatible changes (going from 1.0 to 1.1) in a way that single-number versions don't . Something going from v1 to v2 tells you nothing about the scope of the change, whereas going from 1.3 to 2.0 does. A client that speaks version 1.X of the protocol should be able to talk to any version of 1.X or greater without any loss of functionality, while still giving a 1.(X+1) client extra features.
This also has the benefit operationally of being able to run only the highest version of the 1.X series and knowing that it'll talk compatibly to all the 1.X clients. If you're using integer versions, you either have to maintain semantically unclear maps in the backend, or maintain all the versions. Toby On Sep 23, 2013, at 2:49 PM, Austin King <[email protected]> wrote: > On 9/23/13 2:33 PM, Chris Karlof wrote: >> Hi all, >> >> The Firefox Account and supporting servers are in the process of >> implementing a versioning strategy for API endpoints. Lloyd suggested that >> it would be a good idea for all Identity services to use the same versioning >> strategy. >> >> We're proposing that the API version is the first path element, e.g., >> >> https://some-server/1/some/api/call >> >> alternatively, >> >> https://some-server/v1/some/api/call > > +1 I like v1 as it's descriptive. > > Also, we'll need to have a versioning strategy for > * DOM APIs > * postMessage protocols > > For internal DOM apis (which might be temporary), I've proposed[1] we use the > gecko version number in the API name. > > -- ozten > > > [1] > https://groups.google.com/forum/#!searchin/mozilla.dev.identity/native$20storage$20proposal/mozilla.dev.identity/9iOC_K-Jnj4/01WKpidTqKsJ > >> >> Thoughts? >> >> -chris >> >> P.S. We didn't choose Accept headers because we don't have REST apis and >> they are more cumbersome to deal with. >> _______________________________________________ >> dev-identity mailing list >> [email protected] >> https://lists.mozilla.org/listinfo/dev-identity > > _______________________________________________ > Sync-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/sync-dev _______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
