Hi

>> So if our min_version is 2.1 and the max_version is 2.50. That means
>> alternative implementations need implement all the 50 versions
>> api...that sounds pain...
>
>
> Yes, it's pain, but it's no different than someone who is following the
> Amazon EC2 API, which cuts releases at a regular (sometimes every 2-3 weeks)
> clip.
>
> In Amazon-land, the releases are date-based, instead of
> microversion/incrementing version-based, but the idea is essentially the
> same.
>

Sorry I might be missing something. I don't think one thing justify
the other, plus the problem seems to be the source of truth. I thought
that the idea of big tent in OpenStack was to not having TC to "pick
winners". E.g, If someone wants to have an alternative implementation
of the Baremetal service they will always have to follow Ironic's API?
That's unfair, cause they will always be behind and mostly likely
won't weight much on the decisions of the API.

As I mentioned in the other reply, I find it difficult to talk about
alternative implementations while we do not decouple the API
definition level from the implementation level. If we want alternative
implementations to be a real competitor we need to have a sorta of
program in OpenStack that will be responsible for delivering a
reference API for each type of project (Baremetal, Compute, Identity,
and so on...).

> There is GREAT value to having an API mean ONE thing and ONE thing only. It
> means that developers can code against something that isn't like quicksand
> -- constantly changing meanings.

+1, sure.

Cheers,
Lucas

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to