W3C home > Mailing lists > Public > public-device-apis@w3.org > August 2009

RE: ISSUE-4 (api-versioning): API Versioning [APIs - General]

From: <richard.tibbett@orange-ftgroup.com>
Date: Tue, 25 Aug 2009 15:52:41 +0200
Message-ID: <355A518BC0575547B2A3D6773AAF8EEF2FFC61@ftrdmel1>
To: <public-device-apis@w3.org>
Is it open season on these issues?

Well, how's this for a discussion kick-off: no versioning.

Backward compatibility MUST be maintained in future versions of the same
API. This means that existing methods, parameters, callbacks and classes
MUST NOT be changed if they have been featured in any previous
*approved* versions of a W3C API specification. If changes are required
that intend to break any existing methods, parameters, callbacks and
classes in previously approved W3C API specifications then a new API
name MUST be allocated for this effort.

Just my 2 cents from similar discussions elsewhere :-)

The emphasis of the group must be on getting the basics right much like
W3C Geolocation has been doing (and IMO done well). I'd prefer less
functionality as long as we have a solid foundation to build from in the
future.

> -----Original Message-----
> From: public-device-apis-request@w3.org 
> [mailto:public-device-apis-request@w3.org] On Behalf Of 
> Device APIs and Policy Working Group Issue Tracker
> Sent: 25 August 2009 14:10
> To: public-device-apis@w3.org
> Subject: ISSUE-4 (api-versioning): API Versioning [APIs - General]
> 
> 
> ISSUE-4 (api-versioning): API Versioning [APIs - General]
> 
> http://www.w3.org/2009/dap/track/issues/4
> 
> Raised by: Robin Berjon
> On product: APIs - General
> 
> Let's have the API versioning discussion once and for all. 
> Many are in favour of not having any (i.e. v2 just adds 
> incremental features, and if a radical change is needed the 
> API name is changed), but we need a documented consensus on 
> this early.
> 
> 
> 
> 
Received on Tuesday, 25 August 2009 13:53:24 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:38 UTC