Open Stack

On 02/24/2014 05:26 PM, Christopher Yeoh wrote:
>>> - Whilst we have existing users of the API we also have a lot more
>>>   users in the future. It would be much better to allow them to use
>>>   the API we want to get to as soon as possible, rather than trying
>>>   to evolve the V2 API and forcing them along the transition that
>>> they could otherwise avoid.
>>
>> I'm not sure I understand this.  A key point is that I think any
>> evolving of the V2 API has to be backwards compatible, so there's no
>> forcing them along involved.
> 
> Well other people have been suggesting we can just deprecate parts (be
> it proxying or other bits we really don't like) and then make the
> backwards incompatible change. I think we've already said we'll do it
> for XML for the V2 API and force them off to JSON.

Well, marking deprecated is different than removing it.  We have to get
good data that shows that it's not actually being used before can
actually remove it.  Marking it deprecated at least signals that we
don't consider it actively maintained and that it may go away in the future.

I also consider the XML situation a bit different than changing
specifics of a given API extension, for example.  We're talking about
potentially removing an entire API vs changing an API while it's in use.

>> 2) Take what we have learned from v3 and apply it to v2.  For example:
>>
> <snip>
>>  - revisit a new major API when we get to the point of wanting to
>>    effectively do a re-write, where we are majorly re-thinking the
>>    way our API is designed (from an external perspective, not internal
>>    implementation).
> 
> Ultimately I think what this would means is punting any significant API
> improvements several years down the track and effectively throwing away
> a lot of the worked we've done in the last year on the API

One of the important questions is how much improvement can we make to v2
without breaking backwards compatibility?

What can we *not* do in a backwards compatible manner?  How much does it
hurt to give those things up?  How does that compare to the cost of dual
maintenance?

-- 
Russell Bryant