On 01/14/2015 08:40 PM, Ian Cordasco wrote:
The point was brought up that some recommendations that the working group
forms will be jarring for APIs to implement when going from vN.* to vN+1.0
for both developers and consumers. Client libraries often provide
compatibility (or upgrade-path) versions to help bridge the gap between
going from vN.* to vN+1.0. As a group, we’re looking for feedback from the
developers on the following topics:
- Does this seem preferable?
i think it's a really nice idea to have some sort of guidelines to
assist with the development of compatibility version. i know i would use
it =)
- Does it sound reasonable and maintainable?
good question, my fear would be that we would start strong but fade once
more than a few versions were published. having a clear procedure for
updating and maintaining the guidelines might help.
- Does it seem reasonable as a way of improving user experience and
upgradability?
for me, yes.
If you have a positive feeling for this idea, there are a couple
follow-ups:
- Should the API WG recommend a strategy for this versioning path?
- If so, should the versioning path work like:
- vN.M -> vN.99 -> vN+1.0
We would use .99 to indicate that you it’s compatible with vN.* but
also provides information/endpoints in vN+1)
- or vN.M -> vN+1.0 -> vN+2.0
In this case we would make N+1 be the compatibility version (perhaps
do not allow increments of the minor version) and N+2 would be the version
of the API that is fully in-compliance with the Working Group’s final
recommendations.
this is an interesting idea. i think it would be nice if we could
develop something that would be a clear indication to developers exactly
which version and capabilities an api is presenting.
of those two options, i'm leaning more towards the vN.99 approach.
thanks for bringing it up Ian!
mike
__________________________________________________________________________
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
