Re: [openstack-dev] [API] Upgrading to API WG Recommendations
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
[openstack-dev] [API] Upgrading to API WG Recommendations
Hey all, In the last meeting of the working group, we discussed what the goals of the group are and how those affect existing projects and new ones. In particular, some people seem confused as to whether the group’s goal is to create recommendations for ideal APIs or to document the existing APIs and choose the best practices from those. This is still somewhat up for debate, but most want to shoot for the stars while being willing to compromise. Keep in mind, right now nothing committed to openstack/api-wg is a set in stone. Most of the reviews that are currently in progress are undergoing heavy discussion both on gerrit and in meetings. 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? - Does it sound reasonable and maintainable? - Does it seem reasonable as a way of improving user experience and upgradability? 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. Thanks in advance for your feedback, Ian __ 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
