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