WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-api

[Xen-API] RE: API evolution

To: Rob Hoes <Rob.Hoes@xxxxxxxxxx>
Subject: [Xen-API] RE: API evolution
From: Jonathan Davies <Jonathan.Davies@xxxxxxxxxxxxx>
Date: Fri, 21 May 2010 10:17:33 +0100
Accept-language: en-US
Acceptlanguage: en-US
Cc: "'xen-api@xxxxxxxxxxxxxxxxxxx'" <xen-api@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 21 May 2010 02:17:51 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <7EA643C653F17F4C80DE959E978F10ED798EE30D88@xxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-api-request@lists.xensource.com?subject=help>
List-id: Discussion of API issues surrounding Xen <xen-api.lists.xensource.com>
List-post: <mailto:xen-api@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-api>, <mailto:xen-api-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-api>, <mailto:xen-api-request@lists.xensource.com?subject=unsubscribe>
References: <7EA643C653F17F4C80DE959E978F10ED798EE30D88@xxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-api-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acrt6NHordZcpKmwSC64JdWuB9A+dAK2p+Mw
Thread-topic: API evolution

Hi Rob,

 

This document looks great, and I’m sure will prove to be a big step forward.

 

I have a few comments about areas in which I think the policy could helpfully be clarified a little better:

 

1.       You say that an element in the “prototype” state is just a “stub” that is not yet fully implemented. I’m not sure that this is always appropriate. What about having a prototype that is fully implemented but not yet ready to be fully supported, perhaps because it is an experimental feature?

2.       Into which state(s) can a new API element enter? Must they all start as a prototype in a distinct step or can they go straight into the “published” state?

3.       How are prototypes removed? Can they go straight to the “removed” state or must they first be “deprecated”?

4.       I think it could be clarified when lifecycle transitions can happen. Section 4 discusses what happens on releases, but it’s ambiguous whether transitions can also happen between releases, in the unstable branch. For example, it might be reasonable to state that transitions 3, 4 and 5 can only happen at a release but 1 and 2 can happen at any time?

5.       I think it’s worth explicitly talking about the policy for fields that are maps (typically string->string maps). Is the set of keys similarly controlled?

6.       Traditionally, the other-config field on various objects has been used for prototypes or unsupported features. Will this continue?

 

Sorry, that’s rather a lot of questions and not many suggested answers. I hope that it’s helpful nonetheless.

 

Thanks for your efforts,

Jonathan

 

From: xen-api-bounces@xxxxxxxxxxxxxxxxxxx [mailto:xen-api-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Rob Hoes
Sent: 07 May 2010 14:26
To: 'xen-api@xxxxxxxxxxxxxxxxxxx'
Subject: [Xen-API] API evolution

 

Hi all,

 

Following the changeset related to the API Evolution document I just submitted. This is an update to the document that Dave Scott started a few weeks ago. A PDF is attached.

 

The intention is to agree on the best way to evolve the XenAPI from release to release. Especially now the API is becoming mature, and is used by more and more people, it is important to make clear what exactly is part of the XenAPI, how things may change over time, how we announce changes in terms of release notes, and what sort of compatibility guarantees can be made.

 

The attached document is an initial proposal that would benefit from a good discussion, especially on the topic of compatibility. I’d like to invite everyone who has ideas or experiences related to this to share these.

 

Thanks!

Rob

 

_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/mailman/listinfo/xen-api
<Prev in Thread] Current Thread [Next in Thread>