)]}'
{"specs/juno/api-microversions.rst":[{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"9e5e961456d905ef3c1654570013632ff36693aa","unresolved":false,"context_lines":[{"line_number":16,"context_line":"the REST API to both fix bugs and add new features. Some of these may"},{"line_number":17,"context_line":"be backwards incompatible and so this needs to be done in a way which"},{"line_number":18,"context_line":"both deployers and users of the REST API are able to reasonably manage"},{"line_number":19,"context_line":"the changes which will occur."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"Problem description"},{"line_number":22,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1ae5cdf2_eace4482","line":19,"updated":"2014-06-12 13:21:00.000000000","message":"I think we need to add \"experimental\" versions in here as well. It will be a massive step forward.","commit_id":"6fafaa148c9c91920aa6aa708a58bf9fde6a4ad6"},{"author":{"_account_id":5292,"name":"Christopher Yeoh","email":"cbkyeoh@gmail.com","username":"cyeoh-0"},"change_message_id":"ddafe84d56885592b95a3d3bb9b9b84f4b7c894f","unresolved":false,"context_lines":[{"line_number":16,"context_line":"the REST API to both fix bugs and add new features. Some of these may"},{"line_number":17,"context_line":"be backwards incompatible and so this needs to be done in a way which"},{"line_number":18,"context_line":"both deployers and users of the REST API are able to reasonably manage"},{"line_number":19,"context_line":"the changes which will occur."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"Problem description"},{"line_number":22,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1ae5cdf2_f53c4ee3","line":19,"in_reply_to":"1ae5cdf2_eace4482","updated":"2014-06-13 03:31:22.000000000","message":"agreed","commit_id":"6fafaa148c9c91920aa6aa708a58bf9fde6a4ad6"},{"author":{"_account_id":5174,"name":"Mauro Sergio Martins Rodrigues","email":"maurosr@linux.vnet.ibm.com","username":"maurosr"},"change_message_id":"5edfe26cbb2e9609a4a6ada08065a08afac30d84","unresolved":false,"context_lines":[{"line_number":36,"context_line":"user of the API is able to specify how they would like the REST API to"},{"line_number":37,"context_line":"behave. There also needs to be a default behaviour if no explicit"},{"line_number":38,"context_line":"request is made by the API caller."},{"line_number":39,"context_line":""},{"line_number":40,"context_line":"Proposed change"},{"line_number":41,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":42,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"1ae5cdf2_0943c714","line":39,"updated":"2014-06-03 03:59:20.000000000","message":"I think we should also include here a list with all situations that we can think of and\nwant to cover here, so we can better figure out  which solution would fit better or at\nleast solve most of our problems. Some of what came to my mind:\n  1 - Attribute renaming for requests \u0026 responses\n  2 - Format changes for requests \u0026 responses (several examples from  the work \ndone in v3)\n  3 - Add new parameter (imho the most common case, which doesn\u0027t breaks \ncompatibility)\n  4 - Removal of parameter (should be always avoided, since the clients can choose \nwhat information to show)\n  5 - Change the information type or format (like the time stamps, strings containing \nintegers that for any weird reason - maybe standardization - need to become integers)\n  6 - Different response code (in errors and success)\n  7 - Different policy","commit_id":"6fafaa148c9c91920aa6aa708a58bf9fde6a4ad6"},{"author":{"_account_id":6167,"name":"Ken\u0027ichi Ohmichi","email":"ken1ohmichi@gmail.com","username":"oomichi"},"change_message_id":"d58ee1d51ca6fe508370fc064bb6996f69314389","unresolved":false,"context_lines":[{"line_number":36,"context_line":"user of the API is able to specify how they would like the REST API to"},{"line_number":37,"context_line":"behave. There also needs to be a default behaviour if no explicit"},{"line_number":38,"context_line":"request is made by the API caller."},{"line_number":39,"context_line":""},{"line_number":40,"context_line":"Proposed change"},{"line_number":41,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":42,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"1ae5cdf2_afee53b2","line":39,"in_reply_to":"1ae5cdf2_0943c714","updated":"2014-06-03 05:54:58.000000000","message":"That is a good idea, the list would help us.\n\nAbout the detail,\n\n 1-2, 5: What is difference between 1, 2 and 5 ?\n 3: I agree that 3 would not break compatibility.\n 4. I agree to it.","commit_id":"6fafaa148c9c91920aa6aa708a58bf9fde6a4ad6"},{"author":{"_account_id":5292,"name":"Christopher Yeoh","email":"cbkyeoh@gmail.com","username":"cyeoh-0"},"change_message_id":"ddafe84d56885592b95a3d3bb9b9b84f4b7c894f","unresolved":false,"context_lines":[{"line_number":36,"context_line":"user of the API is able to specify how they would like the REST API to"},{"line_number":37,"context_line":"behave. There also needs to be a default behaviour if no explicit"},{"line_number":38,"context_line":"request is made by the API caller."},{"line_number":39,"context_line":""},{"line_number":40,"context_line":"Proposed change"},{"line_number":41,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":42,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"1ae5cdf2_d53912f3","line":39,"in_reply_to":"1ae5cdf2_4e04e317","updated":"2014-06-13 03:31:22.000000000","message":"So what is considered to be a backwards incompatible change I think is best addressed here:\n\nhttps://wiki.openstack.org/wiki/APIChangeGuidelines\n\nThe wiki page needs expanding, but it is something which is relevant across all the openstack apis and not just nova","commit_id":"6fafaa148c9c91920aa6aa708a58bf9fde6a4ad6"},{"author":{"_account_id":5174,"name":"Mauro Sergio Martins Rodrigues","email":"maurosr@linux.vnet.ibm.com","username":"maurosr"},"change_message_id":"64640c9c6881600c11d7004dc0bb0325f0c9ae93","unresolved":false,"context_lines":[{"line_number":36,"context_line":"user of the API is able to specify how they would like the REST API to"},{"line_number":37,"context_line":"behave. There also needs to be a default behaviour if no explicit"},{"line_number":38,"context_line":"request is made by the API caller."},{"line_number":39,"context_line":""},{"line_number":40,"context_line":"Proposed change"},{"line_number":41,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":42,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"1ae5cdf2_4e04e317","line":39,"in_reply_to":"1ae5cdf2_afee53b2","updated":"2014-06-03 14:21:57.000000000","message":"I mentioned them separated just to clearly enunciate possibilities one by one, like something we want to accept in patches, not exactly saying that they are differente \u003d)","commit_id":"6fafaa148c9c91920aa6aa708a58bf9fde6a4ad6"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"9e5e961456d905ef3c1654570013632ff36693aa","unresolved":false,"context_lines":[{"line_number":50,"context_line":"Properties Common to both proposals"},{"line_number":51,"context_line":"-----------------------------------"},{"line_number":52,"context_line":""},{"line_number":53,"context_line":"* V2.1 will replace V2 (https://review.openstack.org/#/c/84695/)"},{"line_number":54,"context_line":"* Older clients never get broken"},{"line_number":55,"context_line":"* Allow new clients to discover what new parameters they can send"},{"line_number":56,"context_line":"* Allow new clients to request more information from newer APIs"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1ae5cdf2_2a9cac69","line":53,"updated":"2014-06-12 13:21:00.000000000","message":"ideally please reference the blueprint here, not the spec review, it seems more likely to stay current that way.","commit_id":"6fafaa148c9c91920aa6aa708a58bf9fde6a4ad6"},{"author":{"_account_id":5292,"name":"Christopher Yeoh","email":"cbkyeoh@gmail.com","username":"cyeoh-0"},"change_message_id":"ddafe84d56885592b95a3d3bb9b9b84f4b7c894f","unresolved":false,"context_lines":[{"line_number":50,"context_line":"Properties Common to both proposals"},{"line_number":51,"context_line":"-----------------------------------"},{"line_number":52,"context_line":""},{"line_number":53,"context_line":"* V2.1 will replace V2 (https://review.openstack.org/#/c/84695/)"},{"line_number":54,"context_line":"* Older clients never get broken"},{"line_number":55,"context_line":"* Allow new clients to discover what new parameters they can send"},{"line_number":56,"context_line":"* Allow new clients to request more information from newer APIs"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1ae5cdf2_951a2a7b","line":53,"in_reply_to":"1ae5cdf2_2a9cac69","updated":"2014-06-13 03:31:22.000000000","message":"ok, will fix","commit_id":"6fafaa148c9c91920aa6aa708a58bf9fde6a4ad6"},{"author":{"_account_id":6167,"name":"Ken\u0027ichi Ohmichi","email":"ken1ohmichi@gmail.com","username":"oomichi"},"change_message_id":"124aeecd272b91ae5458df50c3740ea27d15b1f4","unresolved":false,"context_lines":[{"line_number":50,"context_line":"Properties Common to both proposals"},{"line_number":51,"context_line":"-----------------------------------"},{"line_number":52,"context_line":""},{"line_number":53,"context_line":"* V2.1 will replace V2 (https://review.openstack.org/#/c/84695/)"},{"line_number":54,"context_line":"* Older clients never get broken"},{"line_number":55,"context_line":"* Allow new clients to discover what new parameters they can send"},{"line_number":56,"context_line":"* Allow new clients to request more information from newer APIs"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1ae5cdf2_af2241b8","line":53,"in_reply_to":"1ae5cdf2_951a2a7b","updated":"2014-06-16 03:05:44.000000000","message":"Done","commit_id":"6fafaa148c9c91920aa6aa708a58bf9fde6a4ad6"},{"author":{"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},"change_message_id":"0a96a6a98b06529113ec50d794129a9a60e2caf1","unresolved":false,"context_lines":[{"line_number":87,"context_line":"* All changes are released as experimental before becoming stable"},{"line_number":88,"context_line":"* Next stable version should be identical to previous experimental"},{"line_number":89,"context_line":"  version, if changes are made, needs another release as experimental"},{"line_number":90,"context_line":"* Need to support all stable versions forever"},{"line_number":91,"context_line":"* Only keep the last experimental version of any API and only for two"},{"line_number":92,"context_line":"  releases (ie delete release following the stable version release)"},{"line_number":93,"context_line":"* Can skip stable releases to have a new experimental version if the"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3ae8d1ca_f0905350","line":90,"updated":"2014-05-29 11:45:30.000000000","message":"Is \u0027all stable version\u0027 means some version just with compatible changes? \n\nI think user only will request different version for incompatible changes.\nFor compatible changes, that won\u0027t effect the client. So may be we only need keep the major stable version? That will make us easy to maintain multiple version code.\n\nAnd how to maintain multiple version code? Does the method of  v2.1 on v3 works?","commit_id":"6fafaa148c9c91920aa6aa708a58bf9fde6a4ad6"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"ef4e5a69d11b6088587c614b8c2e73ff9d9dbee8","unresolved":false,"context_lines":[{"line_number":87,"context_line":"* All changes are released as experimental before becoming stable"},{"line_number":88,"context_line":"* Next stable version should be identical to previous experimental"},{"line_number":89,"context_line":"  version, if changes are made, needs another release as experimental"},{"line_number":90,"context_line":"* Need to support all stable versions forever"},{"line_number":91,"context_line":"* Only keep the last experimental version of any API and only for two"},{"line_number":92,"context_line":"  releases (ie delete release following the stable version release)"},{"line_number":93,"context_line":"* Can skip stable releases to have a new experimental version if the"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1ae5cdf2_8e161954","line":90,"updated":"2014-06-02 10:42:03.000000000","message":"then whats the criteria to deprecate the old Major Version? or we are going to keep all Major Version also forever?","commit_id":"6fafaa148c9c91920aa6aa708a58bf9fde6a4ad6"},{"author":{"_account_id":8430,"name":"Christopher Lefelhocz","email":"christopher.lefelhoc@rackspace.com","username":"leif"},"change_message_id":"a5665aee64eeb21e2b6e29967173b8e30380a09c","unresolved":false,"context_lines":[{"line_number":87,"context_line":"* All changes are released as experimental before becoming stable"},{"line_number":88,"context_line":"* Next stable version should be identical to previous experimental"},{"line_number":89,"context_line":"  version, if changes are made, needs another release as experimental"},{"line_number":90,"context_line":"* Need to support all stable versions forever"},{"line_number":91,"context_line":"* Only keep the last experimental version of any API and only for two"},{"line_number":92,"context_line":"  releases (ie delete release following the stable version release)"},{"line_number":93,"context_line":"* Can skip stable releases to have a new experimental version if the"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1ae5cdf2_e0ce6582","line":90,"in_reply_to":"1ae5cdf2_327388b2","updated":"2014-06-12 14:15:25.000000000","message":"Forever is a long time.  I think a better position may be to some rough criteria defined by the community.  Ie. we know from ops list that folks don\u0027t have clients using the older APIs anymore.","commit_id":"6fafaa148c9c91920aa6aa708a58bf9fde6a4ad6"},{"author":{"_account_id":5174,"name":"Mauro Sergio Martins Rodrigues","email":"maurosr@linux.vnet.ibm.com","username":"maurosr"},"change_message_id":"5edfe26cbb2e9609a4a6ada08065a08afac30d84","unresolved":false,"context_lines":[{"line_number":87,"context_line":"* All changes are released as experimental before becoming stable"},{"line_number":88,"context_line":"* Next stable version should be identical to previous experimental"},{"line_number":89,"context_line":"  version, if changes are made, needs another release as experimental"},{"line_number":90,"context_line":"* Need to support all stable versions forever"},{"line_number":91,"context_line":"* Only keep the last experimental version of any API and only for two"},{"line_number":92,"context_line":"  releases (ie delete release following the stable version release)"},{"line_number":93,"context_line":"* Can skip stable releases to have a new experimental version if the"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1ae5cdf2_a9681388","line":90,"in_reply_to":"1ae5cdf2_8e161954","updated":"2014-06-03 03:59:20.000000000","message":"That was the idea back in portland when this was first dicussed during api-v3 sessions. So IMHO we need to keep all the stable versions, until a new major API,  otherwise it will be no different than release v3, v4, v5, and so on for each incompatible change.\n\nRegarding how to maintain multiple version code, we already do that, with extensions.","commit_id":"6fafaa148c9c91920aa6aa708a58bf9fde6a4ad6"},{"author":{"_account_id":6167,"name":"Ken\u0027ichi Ohmichi","email":"ken1ohmichi@gmail.com","username":"oomichi"},"change_message_id":"d58ee1d51ca6fe508370fc064bb6996f69314389","unresolved":false,"context_lines":[{"line_number":87,"context_line":"* All changes are released as experimental before becoming stable"},{"line_number":88,"context_line":"* Next stable version should be identical to previous experimental"},{"line_number":89,"context_line":"  version, if changes are made, needs another release as experimental"},{"line_number":90,"context_line":"* Need to support all stable versions forever"},{"line_number":91,"context_line":"* Only keep the last experimental version of any API and only for two"},{"line_number":92,"context_line":"  releases (ie delete release following the stable version release)"},{"line_number":93,"context_line":"* Can skip stable releases to have a new experimental version if the"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1ae5cdf2_327388b2","line":90,"in_reply_to":"1ae5cdf2_a9681388","updated":"2014-06-03 05:54:58.000000000","message":"\u003e That was the idea back in portland when this was first\n \u003e dicussed during api-v3 sessions. So IMHO we need to\n \u003e keep all the stable versions, until a new major API\n\nI agree here.\nI also think we need to keep major versions of both previous and current. When v3 is current, we need to support v2 also for v2 clients. I don\u0027t think we need to keep all major versions *forever*.\n\nIf v2.1 API(v2.1 on v3 implementation) can provide v2 compatible APIs, we can remove current v2 implementation code even if v3 is current.","commit_id":"6fafaa148c9c91920aa6aa708a58bf9fde6a4ad6"},{"author":{"_account_id":5174,"name":"Mauro Sergio Martins Rodrigues","email":"maurosr@linux.vnet.ibm.com","username":"maurosr"},"change_message_id":"5edfe26cbb2e9609a4a6ada08065a08afac30d84","unresolved":false,"context_lines":[{"line_number":95,"context_line":""},{"line_number":96,"context_line":"Note that this would mean that the v2.1 API would report as v1.2 (the"},{"line_number":97,"context_line":"first stable version) and any newer stable changes would start as v2.2"},{"line_number":98,"context_line":"of each plugin."},{"line_number":99,"context_line":""},{"line_number":100,"context_line":"Open Questions:"},{"line_number":101,"context_line":"* We need to better define what a backwards incompatible change is"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1ae5cdf2_498a2fc0","line":98,"updated":"2014-06-03 03:59:20.000000000","message":"not sure if I understood it right, but I would suggest to keep v2.1 in the url requests and use versioning through an http header, eventually when a large set of versions for several plugins became a burden too heavy, we bump the v2.1 and deprecate older stables.\nwhat do you think?","commit_id":"6fafaa148c9c91920aa6aa708a58bf9fde6a4ad6"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"ef4e5a69d11b6088587c614b8c2e73ff9d9dbee8","unresolved":false,"context_lines":[{"line_number":98,"context_line":"of each plugin."},{"line_number":99,"context_line":""},{"line_number":100,"context_line":"Open Questions:"},{"line_number":101,"context_line":"* We need to better define what a backwards incompatible change is"},{"line_number":102,"context_line":"* Should a client only be able to specify a major version given that a"},{"line_number":103,"context_line":"  minor version is always by definition backwards compatible. Note"},{"line_number":104,"context_line":"  that the client is still able to query what minor version is"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1ae5cdf2_ee9f9d5d","line":101,"updated":"2014-06-02 10:42:03.000000000","message":"I think this is important open question which decide where  V3 differences (than V2) will go, in major or minor version.","commit_id":"6fafaa148c9c91920aa6aa708a58bf9fde6a4ad6"},{"author":{"_account_id":5174,"name":"Mauro Sergio Martins Rodrigues","email":"maurosr@linux.vnet.ibm.com","username":"maurosr"},"change_message_id":"5edfe26cbb2e9609a4a6ada08065a08afac30d84","unresolved":false,"context_lines":[{"line_number":107,"context_line":"* Should we remove the version number in the URL given its now"},{"line_number":108,"context_line":"  meaningless. This should be possible over the very long term"},{"line_number":109,"context_line":"  (supporting it in the short term is easy, dropping support for /v2"},{"line_number":110,"context_line":"  is very long term).."},{"line_number":111,"context_line":""},{"line_number":112,"context_line":""},{"line_number":113,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1ae5cdf2_c9ef1f86","line":110,"updated":"2014-06-03 03:59:20.000000000","message":"I would keep that, eventually when we have lots of versions of several extensions to maintain would be good to bump it and deprecate a set of plugins versions","commit_id":"6fafaa148c9c91920aa6aa708a58bf9fde6a4ad6"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"9e5e961456d905ef3c1654570013632ff36693aa","unresolved":false,"context_lines":[{"line_number":109,"context_line":"  (supporting it in the short term is easy, dropping support for /v2"},{"line_number":110,"context_line":"  is very long term).."},{"line_number":111,"context_line":""},{"line_number":112,"context_line":""},{"line_number":113,"context_line":"Alternatives"},{"line_number":114,"context_line":"------------"},{"line_number":115,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"1ae5cdf2_6ab794d8","line":112,"updated":"2014-06-12 13:21:00.000000000","message":"I like alaski\u0027s suggestion of a \"high water mark\" global version.\n\nThe client can just request the high water mark version to all plugins, and you get the most recent stable version for each plugin.\n\nThe problem comes with breaking backwards compatibility, and having to rev all the plugins at the same time. But for consistency, this probably is the correct price to pay.","commit_id":"6fafaa148c9c91920aa6aa708a58bf9fde6a4ad6"},{"author":{"_account_id":5174,"name":"Mauro Sergio Martins Rodrigues","email":"maurosr@linux.vnet.ibm.com","username":"maurosr"},"change_message_id":"5edfe26cbb2e9609a4a6ada08065a08afac30d84","unresolved":false,"context_lines":[{"line_number":123,"context_line":"* With each version increment the new API contains an API change that"},{"line_number":124,"context_line":"  may or may not be backwards compatible."},{"line_number":125,"context_line":"* Note that version 204 of the API has all the changes contained in"},{"line_number":126,"context_line":"  versions before it, ie changes in 201, 202 and 203."},{"line_number":127,"context_line":"* It is not possible for a client to request only the API changes"},{"line_number":128,"context_line":"  contained in version 201 and 204. If a client wants the API changes"},{"line_number":129,"context_line":"  contained in version 204, it will also have all the API changes"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1ae5cdf2_693b6b38","line":126,"updated":"2014-06-03 03:59:20.000000000","message":"the problem with this approach is incompatible changes between 202 and 204 for instance, in the very same place, so we lost 202. \n(yeah I know, the API will not change for fun, only when necessary, but with this we have this small window of potential problems).\nI like the evolutionary approach though, I mean if we apply this on the first idea, meaning that stable version x.4 has the contents of x.2 (except in the case a incompatible change, in the very same change that create x.2 is added to x.4), but there, the idea is maintain all stables, so we would be fine.\n\nThat would be a problem to test, mostly in a moment like this when we\u0027re planing branchless tempest test from icehouse and on.","commit_id":"6fafaa148c9c91920aa6aa708a58bf9fde6a4ad6"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"9e5e961456d905ef3c1654570013632ff36693aa","unresolved":false,"context_lines":[{"line_number":140,"context_line":"* If no server version is acceptable, client would need to give up/upgrade"},{"line_number":141,"context_line":"  (long term goal would be eventually be to drop very old microversions)."},{"line_number":142,"context_line":"* plugin specific versioning may not be relevant, though it could be"},{"line_number":143,"context_line":"  left so a version 0 still indicates \"experimental\""},{"line_number":144,"context_line":""},{"line_number":145,"context_line":""},{"line_number":146,"context_line":"Data model impact"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1ae5cdf2_4aec98bb","line":143,"updated":"2014-06-12 13:21:00.000000000","message":"Yeah, you might need a global \"experimental\" version, similar to the per plugin system above.","commit_id":"6fafaa148c9c91920aa6aa708a58bf9fde6a4ad6"},{"author":{"_account_id":5292,"name":"Christopher Yeoh","email":"cbkyeoh@gmail.com","username":"cyeoh-0"},"change_message_id":"ddafe84d56885592b95a3d3bb9b9b84f4b7c894f","unresolved":false,"context_lines":[{"line_number":140,"context_line":"* If no server version is acceptable, client would need to give up/upgrade"},{"line_number":141,"context_line":"  (long term goal would be eventually be to drop very old microversions)."},{"line_number":142,"context_line":"* plugin specific versioning may not be relevant, though it could be"},{"line_number":143,"context_line":"  left so a version 0 still indicates \"experimental\""},{"line_number":144,"context_line":""},{"line_number":145,"context_line":""},{"line_number":146,"context_line":"Data model impact"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1ae5cdf2_588e177a","line":143,"in_reply_to":"1ae5cdf2_4aec98bb","updated":"2014-06-13 03:31:22.000000000","message":"so my initial thought was that a plugin version of 0 would mean that the API offered by the plugin is still experimental even if the global microversion was bumped. So we wouldn\u0027t have a \"global experimental version\" as such.\n\nBut I need to have a good look at all the other similar proposals now too :-)","commit_id":"6fafaa148c9c91920aa6aa708a58bf9fde6a4ad6"},{"author":{"_account_id":8430,"name":"Christopher Lefelhocz","email":"christopher.lefelhoc@rackspace.com","username":"leif"},"change_message_id":"a5665aee64eeb21e2b6e29967173b8e30380a09c","unresolved":false,"context_lines":[{"line_number":141,"context_line":"  (long term goal would be eventually be to drop very old microversions)."},{"line_number":142,"context_line":"* plugin specific versioning may not be relevant, though it could be"},{"line_number":143,"context_line":"  left so a version 0 still indicates \"experimental\""},{"line_number":144,"context_line":""},{"line_number":145,"context_line":""},{"line_number":146,"context_line":"Data model impact"},{"line_number":147,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1ae5cdf2_4071d90a","line":144,"updated":"2014-06-12 14:15:25.000000000","message":"I actually like the microversion implementation idea... I think it forces us to look hard at any truly backwards incompatible changes.  It also may be easier to track in testing.  Say we bump the version because I\u0027m adding something, but I don\u0027t think it has any version incompatible issues.  I could bump the standard tests and see they all pass.  If any fail, I know I have some work to address.","commit_id":"6fafaa148c9c91920aa6aa708a58bf9fde6a4ad6"},{"author":{"_account_id":5174,"name":"Mauro Sergio Martins Rodrigues","email":"maurosr@linux.vnet.ibm.com","username":"maurosr"},"change_message_id":"5edfe26cbb2e9609a4a6ada08065a08afac30d84","unresolved":false,"context_lines":[{"line_number":176,"context_line":""},{"line_number":177,"context_line":"Other deployer impact"},{"line_number":178,"context_line":"---------------------"},{"line_number":179,"context_line":""},{"line_number":180,"context_line":"Discuss things that will affect how you deploy and configure OpenStack"},{"line_number":181,"context_line":"that have not already been mentioned, such as:"},{"line_number":182,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"1ae5cdf2_297243e5","line":179,"updated":"2014-06-03 03:59:20.000000000","message":"I think it\u0027s worthy to mention how we\u0027re going to deal with it on novaclient side and also in tempest.\nI had one idea regarding how to test multiple versions in tempest, pretty much a plugin-able approach like what v3 was based, but need to check how tempest is setup in the gate before claim it\u0027s a solution. If I confirm that will draft a qa-spec and inform the link (of course, only if we chose the first approach)","commit_id":"6fafaa148c9c91920aa6aa708a58bf9fde6a4ad6"},{"author":{"_account_id":5292,"name":"Christopher Yeoh","email":"cbkyeoh@gmail.com","username":"cyeoh-0"},"change_message_id":"ddafe84d56885592b95a3d3bb9b9b84f4b7c894f","unresolved":false,"context_lines":[{"line_number":176,"context_line":""},{"line_number":177,"context_line":"Other deployer impact"},{"line_number":178,"context_line":"---------------------"},{"line_number":179,"context_line":""},{"line_number":180,"context_line":"Discuss things that will affect how you deploy and configure OpenStack"},{"line_number":181,"context_line":"that have not already been mentioned, such as:"},{"line_number":182,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"1ae5cdf2_583297f2","line":179,"in_reply_to":"1ae5cdf2_297243e5","updated":"2014-06-13 03:31:22.000000000","message":"the tempest side is going to be a bit of a learn as we go because of a limit on how much compute capacity to be able to test every possible combination\n\nOn the novaclient side we need to think a lot harder about what python-novaclient is meant to be. Is it meant to be a very thin layer on top of the REST API (meaning users of python-novaclient need to change with the underlying API) or is meant to be an insulating layer between the user and the REST API (eg we try to keep it stable for as long as we can, but have version bumps every now and then.","commit_id":"6fafaa148c9c91920aa6aa708a58bf9fde6a4ad6"},{"author":{"_account_id":1849,"name":"Joe Gordon","email":"joe.gordon0@gmail.com","username":"jogo"},"change_message_id":"9ae902dbf176867814bf81dfcf1ad37e2fb17a31","unresolved":false,"context_lines":[{"line_number":20,"context_line":"done in a way which both deployers and users of the REST API are able"},{"line_number":21,"context_line":"to reasonably manage the changes which will occur."},{"line_number":22,"context_line":""},{"line_number":23,"context_line":"At the same time, we really would like a way to introduce new APIs"},{"line_number":24,"context_line":"as \"experimental\", have no backwards compatibility guarantees until"},{"line_number":25,"context_line":"we are happy the API is stable and well tested."},{"line_number":26,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"1ae5cdf2_55eee2ed","line":23,"updated":"2014-06-20 05:35:11.000000000","message":"While I don\u0027t disagree with this statement, I am not sure if I agree with it either. even if we call something \"experimental\" folks may still use it with the assumption of stability","commit_id":"8c74a075f997f9e52324ecfee1c5962ae48ff47d"},{"author":{"_account_id":6167,"name":"Ken\u0027ichi Ohmichi","email":"ken1ohmichi@gmail.com","username":"oomichi"},"change_message_id":"17d5abbfc1831114b2213625077805d30cdc7e4b","unresolved":false,"context_lines":[{"line_number":20,"context_line":"done in a way which both deployers and users of the REST API are able"},{"line_number":21,"context_line":"to reasonably manage the changes which will occur."},{"line_number":22,"context_line":""},{"line_number":23,"context_line":"At the same time, we really would like a way to introduce new APIs"},{"line_number":24,"context_line":"as \"experimental\", have no backwards compatibility guarantees until"},{"line_number":25,"context_line":"we are happy the API is stable and well tested."},{"line_number":26,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"1ae5cdf2_f899a36d","line":23,"in_reply_to":"1ae5cdf2_55eee2ed","updated":"2014-06-20 08:37:54.000000000","message":"Just one idea for making new APIs more experimental:\n\nEach API has API extension version(based on line70 proposal), and the version of a new API should be 0.\nWhen getting extension list via \"GET extensions\" API, the list does not include extensions of version 0. Clients cannot know new API existences.\n\nTo make more difficult, how about overwriting the policies of new APIs(version 0) with \"rule:admin_api\"? Normal clients cannot use them even if they know API usages.","commit_id":"8c74a075f997f9e52324ecfee1c5962ae48ff47d"},{"author":{"_account_id":5292,"name":"Christopher Yeoh","email":"cbkyeoh@gmail.com","username":"cyeoh-0"},"change_message_id":"983eac57cd9acfb3ce925c5d75f25fe73f699961","unresolved":false,"context_lines":[{"line_number":20,"context_line":"done in a way which both deployers and users of the REST API are able"},{"line_number":21,"context_line":"to reasonably manage the changes which will occur."},{"line_number":22,"context_line":""},{"line_number":23,"context_line":"At the same time, we really would like a way to introduce new APIs"},{"line_number":24,"context_line":"as \"experimental\", have no backwards compatibility guarantees until"},{"line_number":25,"context_line":"we are happy the API is stable and well tested."},{"line_number":26,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"1ae5cdf2_162d1746","line":23,"in_reply_to":"1ae5cdf2_55eee2ed","updated":"2014-06-23 00:26:27.000000000","message":"Well we can\u0027t stop them using it with the assumption of stability, but we are being very clear that it is *not* a stable API. Under those circumstances I think its reasonable that we can make backwards incompatible changes to the API.","commit_id":"8c74a075f997f9e52324ecfee1c5962ae48ff47d"},{"author":{"_account_id":5292,"name":"Christopher Yeoh","email":"cbkyeoh@gmail.com","username":"cyeoh-0"},"change_message_id":"983eac57cd9acfb3ce925c5d75f25fe73f699961","unresolved":false,"context_lines":[{"line_number":20,"context_line":"done in a way which both deployers and users of the REST API are able"},{"line_number":21,"context_line":"to reasonably manage the changes which will occur."},{"line_number":22,"context_line":""},{"line_number":23,"context_line":"At the same time, we really would like a way to introduce new APIs"},{"line_number":24,"context_line":"as \"experimental\", have no backwards compatibility guarantees until"},{"line_number":25,"context_line":"we are happy the API is stable and well tested."},{"line_number":26,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"1ae5cdf2_56231f57","line":23,"in_reply_to":"1ae5cdf2_f899a36d","updated":"2014-06-23 00:26:27.000000000","message":"so my preference would be to avoid these sorts of things because it makes it harder for those who want to use the experimental APIs. We could perhaps return a header saying the api is experimental (but people may not see the header anyway). \n\nI\u0027d prefer we try first communicating better that version 0 means experimental - and if we always do this (new APIs are always experimental) then perhaps that will be well known across openstack apis?","commit_id":"8c74a075f997f9e52324ecfee1c5962ae48ff47d"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"b1364bafbef6a9b53b3e97f82fdb6d1e2ec9bd60","unresolved":false,"context_lines":[{"line_number":45,"context_line":""},{"line_number":46,"context_line":"So each API version is one of:"},{"line_number":47,"context_line":""},{"line_number":48,"context_line":"* stable: will be available for ever"},{"line_number":49,"context_line":""},{"line_number":50,"context_line":"* experimental: may be removed, or changed in any way, at any time"},{"line_number":51,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"1ae5cdf2_c0bb5cc2","line":48,"updated":"2014-06-18 14:46:05.000000000","message":"s/for ever/forever/","commit_id":"8c74a075f997f9e52324ecfee1c5962ae48ff47d"},{"author":{"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},"change_message_id":"759451b4f4ddc6bc8f29328fadf965c79bf0cd9e","unresolved":false,"context_lines":[{"line_number":95,"context_line":""},{"line_number":96,"context_line":"Creating backwards compatible changes will require all the plugins to offer"},{"line_number":97,"context_line":"the new version. This helps discourage backwards compatible changes, but"},{"line_number":98,"context_line":"allows us to evolve things in the near future."},{"line_number":99,"context_line":""},{"line_number":100,"context_line":"We provide zero support for out of tree extensions. Having a global version"},{"line_number":101,"context_line":"makes them harder to deal with, but we can ignore that here. Allowing"}],"source_content_type":"text/x-rst","patch_set":5,"id":"1ae5cdf2_4d22ce01","line":98,"updated":"2014-06-20 13:58:22.000000000","message":"why we discourage backwards compatible changes? or you mean we discourage backwards incompatible changes?","commit_id":"8c74a075f997f9e52324ecfee1c5962ae48ff47d"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"da74a564f366f94746fbbafbfd46817ec12262e7","unresolved":false,"context_lines":[{"line_number":95,"context_line":""},{"line_number":96,"context_line":"Creating backwards compatible changes will require all the plugins to offer"},{"line_number":97,"context_line":"the new version. This helps discourage backwards compatible changes, but"},{"line_number":98,"context_line":"allows us to evolve things in the near future."},{"line_number":99,"context_line":""},{"line_number":100,"context_line":"We provide zero support for out of tree extensions. Having a global version"},{"line_number":101,"context_line":"makes them harder to deal with, but we can ignore that here. Allowing"}],"source_content_type":"text/x-rst","patch_set":5,"id":"1ae5cdf2_7db38a9a","line":98,"in_reply_to":"1ae5cdf2_16d4371e","updated":"2014-06-23 12:38:11.000000000","message":"+1","commit_id":"8c74a075f997f9e52324ecfee1c5962ae48ff47d"},{"author":{"_account_id":5292,"name":"Christopher Yeoh","email":"cbkyeoh@gmail.com","username":"cyeoh-0"},"change_message_id":"983eac57cd9acfb3ce925c5d75f25fe73f699961","unresolved":false,"context_lines":[{"line_number":95,"context_line":""},{"line_number":96,"context_line":"Creating backwards compatible changes will require all the plugins to offer"},{"line_number":97,"context_line":"the new version. This helps discourage backwards compatible changes, but"},{"line_number":98,"context_line":"allows us to evolve things in the near future."},{"line_number":99,"context_line":""},{"line_number":100,"context_line":"We provide zero support for out of tree extensions. Having a global version"},{"line_number":101,"context_line":"makes them harder to deal with, but we can ignore that here. Allowing"}],"source_content_type":"text/x-rst","patch_set":5,"id":"1ae5cdf2_16d4371e","line":98,"in_reply_to":"1ae5cdf2_4d22ce01","updated":"2014-06-23 00:26:27.000000000","message":"backwards incompatible changes are always going to be more long term maintenance so its good to discourage them, but sometimes we just need to do it so we need a way of allowing it.","commit_id":"8c74a075f997f9e52324ecfee1c5962ae48ff47d"},{"author":{"_account_id":5441,"name":"Andrew Laski","email":"andrew@lascii.com","username":"alaski"},"change_message_id":"5a0d67248925ec81abf79bb3c1ed6be960e4de43","unresolved":false,"context_lines":[{"line_number":100,"context_line":"We provide zero support for out of tree extensions. Having a global version"},{"line_number":101,"context_line":"makes them harder to deal with, but we can ignore that here. Allowing"},{"line_number":102,"context_line":"experimental extensions should allow us to merge things and evolve them in"},{"line_number":103,"context_line":"tree, hopefully reducing the temptation to maintain an API outside the tree."},{"line_number":104,"context_line":""},{"line_number":105,"context_line":"What does the version number mean?"},{"line_number":106,"context_line":"----------------------------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"1ae5cdf2_6551bad8","line":103,"updated":"2014-06-18 13:56:04.000000000","message":"This may end up being a big source of contention and I think it would be good to have some sort of proposal ready for how deployers can deal with this.  I think the key thing with out of tree extensions is that there should be a boundary or clear delineation between them and the in tree API.  Users should know when they\u0027re using an out of tree extension, and they should be considered outside of the versioning of the in tree API.","commit_id":"8c74a075f997f9e52324ecfee1c5962ae48ff47d"},{"author":{"_account_id":5441,"name":"Andrew Laski","email":"andrew@lascii.com","username":"alaski"},"change_message_id":"c87750417e75d6d36dc69bc934bc08853262f9b0","unresolved":false,"context_lines":[{"line_number":100,"context_line":"We provide zero support for out of tree extensions. Having a global version"},{"line_number":101,"context_line":"makes them harder to deal with, but we can ignore that here. Allowing"},{"line_number":102,"context_line":"experimental extensions should allow us to merge things and evolve them in"},{"line_number":103,"context_line":"tree, hopefully reducing the temptation to maintain an API outside the tree."},{"line_number":104,"context_line":""},{"line_number":105,"context_line":"What does the version number mean?"},{"line_number":106,"context_line":"----------------------------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"1ae5cdf2_c6d153fc","line":103,"in_reply_to":"1ae5cdf2_60736816","updated":"2014-06-20 20:57:27.000000000","message":"I agree with discouraging out of tree extensions.  I just don\u0027t think we can say there\u0027s zero support for them.  Especially around the admin-api as you mentioned.","commit_id":"8c74a075f997f9e52324ecfee1c5962ae48ff47d"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"b1364bafbef6a9b53b3e97f82fdb6d1e2ec9bd60","unresolved":false,"context_lines":[{"line_number":100,"context_line":"We provide zero support for out of tree extensions. Having a global version"},{"line_number":101,"context_line":"makes them harder to deal with, but we can ignore that here. Allowing"},{"line_number":102,"context_line":"experimental extensions should allow us to merge things and evolve them in"},{"line_number":103,"context_line":"tree, hopefully reducing the temptation to maintain an API outside the tree."},{"line_number":104,"context_line":""},{"line_number":105,"context_line":"What does the version number mean?"},{"line_number":106,"context_line":"----------------------------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"1ae5cdf2_60736816","line":103,"in_reply_to":"1ae5cdf2_6551bad8","updated":"2014-06-18 14:46:05.000000000","message":"I\u0027m very much in favor of making it difficult to have/use out of tree extensions. It\u0027s important for the health of the project to define its API instead of what we have right now.\n\nThat said, I think that as long as you can mark your own extension as experimental (forever) then adding admin-only things you need to manage your cloud should be acceptable. This will help avoid deployers exposing user-facing APIs that create incompatibility between clouds, which is a good thing I think.","commit_id":"8c74a075f997f9e52324ecfee1c5962ae48ff47d"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"da74a564f366f94746fbbafbfd46817ec12262e7","unresolved":false,"context_lines":[{"line_number":100,"context_line":"We provide zero support for out of tree extensions. Having a global version"},{"line_number":101,"context_line":"makes them harder to deal with, but we can ignore that here. Allowing"},{"line_number":102,"context_line":"experimental extensions should allow us to merge things and evolve them in"},{"line_number":103,"context_line":"tree, hopefully reducing the temptation to maintain an API outside the tree."},{"line_number":104,"context_line":""},{"line_number":105,"context_line":"What does the version number mean?"},{"line_number":106,"context_line":"----------------------------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"1ae5cdf2_1d8d26d4","line":103,"in_reply_to":"1ae5cdf2_c6d153fc","updated":"2014-06-23 12:38:11.000000000","message":"Well I am just saying, out of tree are always considered experimental.","commit_id":"8c74a075f997f9e52324ecfee1c5962ae48ff47d"},{"author":{"_account_id":5441,"name":"Andrew Laski","email":"andrew@lascii.com","username":"alaski"},"change_message_id":"5a0d67248925ec81abf79bb3c1ed6be960e4de43","unresolved":false,"context_lines":[{"line_number":108,"context_line":"Stable versions are even numbered, experimental versions are odd numbered."},{"line_number":109,"context_line":""},{"line_number":110,"context_line":"Backwards incompatibility is shown via bumping the major version number."},{"line_number":111,"context_line":"Any change that adds functionality bumps the major version."},{"line_number":112,"context_line":""},{"line_number":113,"context_line":"To save confusion, will not use \"x.0\" or \"0.x\"."},{"line_number":114,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"1ae5cdf2_ba175da2","line":111,"updated":"2014-06-18 13:56:04.000000000","message":"What does this mean exactly?  Adding a new optional request parameter can be seen as adding functionality but is backwards compatible and therefore could be done with a minor version bump.","commit_id":"8c74a075f997f9e52324ecfee1c5962ae48ff47d"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"da74a564f366f94746fbbafbfd46817ec12262e7","unresolved":false,"context_lines":[{"line_number":108,"context_line":"Stable versions are even numbered, experimental versions are odd numbered."},{"line_number":109,"context_line":""},{"line_number":110,"context_line":"Backwards incompatibility is shown via bumping the major version number."},{"line_number":111,"context_line":"Any change that adds functionality bumps the major version."},{"line_number":112,"context_line":""},{"line_number":113,"context_line":"To save confusion, will not use \"x.0\" or \"0.x\"."},{"line_number":114,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"1ae5cdf2_cd30f058","line":111,"in_reply_to":"1ae5cdf2_ba175da2","updated":"2014-06-23 12:38:11.000000000","message":"Yeah, thats a bad typo, it should say bumps the minor version :(","commit_id":"8c74a075f997f9e52324ecfee1c5962ae48ff47d"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"b1364bafbef6a9b53b3e97f82fdb6d1e2ec9bd60","unresolved":false,"context_lines":[{"line_number":110,"context_line":"Backwards incompatibility is shown via bumping the major version number."},{"line_number":111,"context_line":"Any change that adds functionality bumps the major version."},{"line_number":112,"context_line":""},{"line_number":113,"context_line":"To save confusion, will not use \"x.0\" or \"0.x\"."},{"line_number":114,"context_line":""},{"line_number":115,"context_line":"How the client requests a version"},{"line_number":116,"context_line":"---------------------------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"1ae5cdf2_34c44191","line":113,"updated":"2014-06-18 14:46:05.000000000","message":"I\u0027m confused about what this means. I\u0027m also generally confused about the experimental/stable indication with odd numbers. Unlike the linux kernel, we can\u0027t be on an odd version number for a long time, then switch to an even one when we go stable (unless I\u0027m missing something).\n\nFor my and Andrew\u0027s questions, perhaps an example of interleaving stable and experimental development as part of a regular release cycle would be helpful here?","commit_id":"8c74a075f997f9e52324ecfee1c5962ae48ff47d"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"da74a564f366f94746fbbafbfd46817ec12262e7","unresolved":false,"context_lines":[{"line_number":110,"context_line":"Backwards incompatibility is shown via bumping the major version number."},{"line_number":111,"context_line":"Any change that adds functionality bumps the major version."},{"line_number":112,"context_line":""},{"line_number":113,"context_line":"To save confusion, will not use \"x.0\" or \"0.x\"."},{"line_number":114,"context_line":""},{"line_number":115,"context_line":"How the client requests a version"},{"line_number":116,"context_line":"---------------------------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"1ae5cdf2_ad79e4fd","line":113,"in_reply_to":"1ae5cdf2_34c44191","updated":"2014-06-23 12:38:11.000000000","message":"That was my plan here, switch to even when we go stable, but have it exposed publicly to allow testing (otherwise, we find that no one tests these things).","commit_id":"8c74a075f997f9e52324ecfee1c5962ae48ff47d"},{"author":{"_account_id":6167,"name":"Ken\u0027ichi Ohmichi","email":"ken1ohmichi@gmail.com","username":"oomichi"},"change_message_id":"17d5abbfc1831114b2213625077805d30cdc7e4b","unresolved":false,"context_lines":[{"line_number":110,"context_line":"Backwards incompatibility is shown via bumping the major version number."},{"line_number":111,"context_line":"Any change that adds functionality bumps the major version."},{"line_number":112,"context_line":""},{"line_number":113,"context_line":"To save confusion, will not use \"x.0\" or \"0.x\"."},{"line_number":114,"context_line":""},{"line_number":115,"context_line":"How the client requests a version"},{"line_number":116,"context_line":"---------------------------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"1ae5cdf2_e97c7773","line":113,"in_reply_to":"1ae5cdf2_34c44191","updated":"2014-06-20 08:37:54.000000000","message":"agree to clarify experimental more.\n\nI think experimental version would be a single always and it should not be exposed to public, it is just for the development. So how about defining \"experimental\" as the version instead of \"x.y\"?","commit_id":"8c74a075f997f9e52324ecfee1c5962ae48ff47d"},{"author":{"_account_id":1849,"name":"Joe Gordon","email":"joe.gordon0@gmail.com","username":"jogo"},"change_message_id":"9ae902dbf176867814bf81dfcf1ad37e2fb17a31","unresolved":false,"context_lines":[{"line_number":112,"context_line":""},{"line_number":113,"context_line":"To save confusion, will not use \"x.0\" or \"0.x\"."},{"line_number":114,"context_line":""},{"line_number":115,"context_line":"How the client requests a version"},{"line_number":116,"context_line":"---------------------------------"},{"line_number":117,"context_line":""},{"line_number":118,"context_line":"Client used an accepts header to request a specific major version."}],"source_content_type":"text/x-rst","patch_set":5,"id":"1ae5cdf2_b58c8636","line":115,"updated":"2014-06-20 05:35:11.000000000","message":"I think we should agree on the mechanics of this section before approving the v2.1 on v3 spec","commit_id":"8c74a075f997f9e52324ecfee1c5962ae48ff47d"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"b1364bafbef6a9b53b3e97f82fdb6d1e2ec9bd60","unresolved":false,"context_lines":[{"line_number":115,"context_line":"How the client requests a version"},{"line_number":116,"context_line":"---------------------------------"},{"line_number":117,"context_line":""},{"line_number":118,"context_line":"Client used an accepts header to request a specific major version."},{"line_number":119,"context_line":"As the minor versions are backwards compatible, you just get the latest"},{"line_number":120,"context_line":"stable version returned."},{"line_number":121,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"1ae5cdf2_1443c513","line":118,"updated":"2014-06-18 14:46:05.000000000","message":"s/used/uses/ ?","commit_id":"8c74a075f997f9e52324ecfee1c5962ae48ff47d"},{"author":{"_account_id":1849,"name":"Joe Gordon","email":"joe.gordon0@gmail.com","username":"jogo"},"change_message_id":"9ae902dbf176867814bf81dfcf1ad37e2fb17a31","unresolved":false,"context_lines":[{"line_number":119,"context_line":"As the minor versions are backwards compatible, you just get the latest"},{"line_number":120,"context_line":"stable version returned."},{"line_number":121,"context_line":""},{"line_number":122,"context_line":"To get what we used to call v2, request:::"},{"line_number":123,"context_line":""},{"line_number":124,"context_line":"  Accept: application/vnd.openstack-org.compute-v2+json"},{"line_number":125,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"1ae5cdf2_359f9651","line":122,"updated":"2014-06-20 05:35:11.000000000","message":"From the v2.1 on v3 spec, it was unclear to me if we want to start the microversioning support at v2 or at v2.1?","commit_id":"8c74a075f997f9e52324ecfee1c5962ae48ff47d"},{"author":{"_account_id":6167,"name":"Ken\u0027ichi Ohmichi","email":"ken1ohmichi@gmail.com","username":"oomichi"},"change_message_id":"17d5abbfc1831114b2213625077805d30cdc7e4b","unresolved":false,"context_lines":[{"line_number":119,"context_line":"As the minor versions are backwards compatible, you just get the latest"},{"line_number":120,"context_line":"stable version returned."},{"line_number":121,"context_line":""},{"line_number":122,"context_line":"To get what we used to call v2, request:::"},{"line_number":123,"context_line":""},{"line_number":124,"context_line":"  Accept: application/vnd.openstack-org.compute-v2+json"},{"line_number":125,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"1ae5cdf2_de320f5d","line":122,"in_reply_to":"1ae5cdf2_359f9651","updated":"2014-06-20 08:37:54.000000000","message":"That is a nice point, and it would depends on line165 discussion now.","commit_id":"8c74a075f997f9e52324ecfee1c5962ae48ff47d"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"da74a564f366f94746fbbafbfd46817ec12262e7","unresolved":false,"context_lines":[{"line_number":119,"context_line":"As the minor versions are backwards compatible, you just get the latest"},{"line_number":120,"context_line":"stable version returned."},{"line_number":121,"context_line":""},{"line_number":122,"context_line":"To get what we used to call v2, request:::"},{"line_number":123,"context_line":""},{"line_number":124,"context_line":"  Accept: application/vnd.openstack-org.compute-v2+json"},{"line_number":125,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"1ae5cdf2_930f6739","line":122,"in_reply_to":"1ae5cdf2_de320f5d","updated":"2014-06-23 12:38:11.000000000","message":"v2.1 replaces v2, in my view, in a way the client doesn\u0027t notice, but in the mean time, the client can request it explicitly as an experimental version, maybe.","commit_id":"8c74a075f997f9e52324ecfee1c5962ae48ff47d"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"b1364bafbef6a9b53b3e97f82fdb6d1e2ec9bd60","unresolved":false,"context_lines":[{"line_number":143,"context_line":"For a major version to become stable, it should be implemented by all API"},{"line_number":144,"context_line":"extensions, otherwise the point of these global versions will be greatly"},{"line_number":145,"context_line":"reduced. This change may involve zero changes to the API, but is required"},{"line_number":146,"context_line":"to ensure the API remains consistent."},{"line_number":147,"context_line":""},{"line_number":148,"context_line":"TODO..."},{"line_number":149,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"1ae5cdf2_d4c15de5","line":146,"updated":"2014-06-18 14:46:05.000000000","message":"This is really pretty far off from what I was expecting we were going to get to. I think the client needs to request version \"2.132\" and receive a failure if the server can\u0027t satisfy that new of a version, or a suitably-compatible result (which may have additive changes but nothing breaking).","commit_id":"8c74a075f997f9e52324ecfee1c5962ae48ff47d"},{"author":{"_account_id":6167,"name":"Ken\u0027ichi Ohmichi","email":"ken1ohmichi@gmail.com","username":"oomichi"},"change_message_id":"17d5abbfc1831114b2213625077805d30cdc7e4b","unresolved":false,"context_lines":[{"line_number":143,"context_line":"For a major version to become stable, it should be implemented by all API"},{"line_number":144,"context_line":"extensions, otherwise the point of these global versions will be greatly"},{"line_number":145,"context_line":"reduced. This change may involve zero changes to the API, but is required"},{"line_number":146,"context_line":"to ensure the API remains consistent."},{"line_number":147,"context_line":""},{"line_number":148,"context_line":"TODO..."},{"line_number":149,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"1ae5cdf2_694dc73a","line":146,"in_reply_to":"1ae5cdf2_35cdd65d","updated":"2014-06-20 08:37:54.000000000","message":"EC2 API is provided by a single vender but OpenStack API is provided by multiple ones. so Dates version would represent different things between venders and that is one concern as line 321.","commit_id":"8c74a075f997f9e52324ecfee1c5962ae48ff47d"},{"author":{"_account_id":1849,"name":"Joe Gordon","email":"joe.gordon0@gmail.com","username":"jogo"},"change_message_id":"9ae902dbf176867814bf81dfcf1ad37e2fb17a31","unresolved":false,"context_lines":[{"line_number":143,"context_line":"For a major version to become stable, it should be implemented by all API"},{"line_number":144,"context_line":"extensions, otherwise the point of these global versions will be greatly"},{"line_number":145,"context_line":"reduced. This change may involve zero changes to the API, but is required"},{"line_number":146,"context_line":"to ensure the API remains consistent."},{"line_number":147,"context_line":""},{"line_number":148,"context_line":"TODO..."},{"line_number":149,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"1ae5cdf2_35cdd65d","line":146,"in_reply_to":"1ae5cdf2_d4c15de5","updated":"2014-06-20 05:35:11.000000000","message":"I agree with Dan. I am also personally a fan of the API versioning that EC2 uses (Dates), so they are currently on API Version 2014-05-01\n\nI am not sure how we would do experimental features if we use the dates model, but I think there are few options.","commit_id":"8c74a075f997f9e52324ecfee1c5962ae48ff47d"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"da74a564f366f94746fbbafbfd46817ec12262e7","unresolved":false,"context_lines":[{"line_number":143,"context_line":"For a major version to become stable, it should be implemented by all API"},{"line_number":144,"context_line":"extensions, otherwise the point of these global versions will be greatly"},{"line_number":145,"context_line":"reduced. This change may involve zero changes to the API, but is required"},{"line_number":146,"context_line":"to ensure the API remains consistent."},{"line_number":147,"context_line":""},{"line_number":148,"context_line":"TODO..."},{"line_number":149,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"1ae5cdf2_8df50853","line":146,"in_reply_to":"1ae5cdf2_d4c15de5","updated":"2014-06-23 12:38:11.000000000","message":"Yeah, that was my plan A, and I ended up doing this to simplify things.\n\nThe idea being that if its backwards compatible you don\u0027t really care, unless you want to discover if a particular feature is available. But I duno if thats right.","commit_id":"8c74a075f997f9e52324ecfee1c5962ae48ff47d"},{"author":{"_account_id":5441,"name":"Andrew Laski","email":"andrew@lascii.com","username":"alaski"},"change_message_id":"5a0d67248925ec81abf79bb3c1ed6be960e4de43","unresolved":false,"context_lines":[{"line_number":162,"context_line":""},{"line_number":163,"context_line":"    {"},{"line_number":164,"context_line":"        \"versions\": {"},{"line_number":165,"context_line":"          \"2.2\": \"application/vnd.openstack-org.compute-v2+json\","},{"line_number":166,"context_line":"          \"2.4\": \"application/vnd.openstack-org.compute-v2+json\","},{"line_number":167,"context_line":"          \"latest\": \"application/vnd.openstack-org.compute-v2+json\","},{"line_number":168,"context_line":"          \"2.5\": \"application/vnd.openstack-org.compute-v2-experimental+json\","}],"source_content_type":"text/x-rst","patch_set":5,"id":"1ae5cdf2_c5528e12","line":165,"updated":"2014-06-18 13:56:04.000000000","message":"Should the global version be major/minor?  Backwards incompatible API changes aren\u0027t happening at this level so I think leaving that signal is fine at the extension level.  The global version could be something like max([extension[\u0027last_changed\u0027] for extension in extensions), or just a monotonically increasing int.","commit_id":"8c74a075f997f9e52324ecfee1c5962ae48ff47d"},{"author":{"_account_id":6167,"name":"Ken\u0027ichi Ohmichi","email":"ken1ohmichi@gmail.com","username":"oomichi"},"change_message_id":"833d2c3dc3e55aa8a0e103f601be3c592d1d7a7e","unresolved":false,"context_lines":[{"line_number":162,"context_line":""},{"line_number":163,"context_line":"    {"},{"line_number":164,"context_line":"        \"versions\": {"},{"line_number":165,"context_line":"          \"2.2\": \"application/vnd.openstack-org.compute-v2+json\","},{"line_number":166,"context_line":"          \"2.4\": \"application/vnd.openstack-org.compute-v2+json\","},{"line_number":167,"context_line":"          \"latest\": \"application/vnd.openstack-org.compute-v2+json\","},{"line_number":168,"context_line":"          \"2.5\": \"application/vnd.openstack-org.compute-v2-experimental+json\","}],"source_content_type":"text/x-rst","patch_set":5,"id":"1ae5cdf2_b191cd9b","line":165,"in_reply_to":"1ae5cdf2_06e25b9f","updated":"2014-06-23 01:21:19.000000000","message":"I also am interested in how to increase a single global microversion. If we increase a single global microversion as stable version by each extension backwards incompatible change, many stable microversions are created.\n\nNow we are testing v2json, v2xml and v3json with Tempest. and each testing cost is 7-10 minutes[1]. If creating a lot of stable microversions, the testing cost will be so big. I think we need to avoid such situation.\n\n[1]: http://lists.openstack.org/pipermail/openstack-dev/2014-June/037370.html","commit_id":"8c74a075f997f9e52324ecfee1c5962ae48ff47d"},{"author":{"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},"change_message_id":"7335f1e84709f46a39c47c93980aa20fa14f5737","unresolved":false,"context_lines":[{"line_number":162,"context_line":""},{"line_number":163,"context_line":"    {"},{"line_number":164,"context_line":"        \"versions\": {"},{"line_number":165,"context_line":"          \"2.2\": \"application/vnd.openstack-org.compute-v2+json\","},{"line_number":166,"context_line":"          \"2.4\": \"application/vnd.openstack-org.compute-v2+json\","},{"line_number":167,"context_line":"          \"latest\": \"application/vnd.openstack-org.compute-v2+json\","},{"line_number":168,"context_line":"          \"2.5\": \"application/vnd.openstack-org.compute-v2-experimental+json\","}],"source_content_type":"text/x-rst","patch_set":5,"id":"1ae5cdf2_94a00c93","line":165,"in_reply_to":"1ae5cdf2_1c850807","updated":"2014-06-24 07:56:07.000000000","message":"yeah, that also is micro-version what I understand.","commit_id":"8c74a075f997f9e52324ecfee1c5962ae48ff47d"},{"author":{"_account_id":5441,"name":"Andrew Laski","email":"andrew@lascii.com","username":"alaski"},"change_message_id":"c87750417e75d6d36dc69bc934bc08853262f9b0","unresolved":false,"context_lines":[{"line_number":162,"context_line":""},{"line_number":163,"context_line":"    {"},{"line_number":164,"context_line":"        \"versions\": {"},{"line_number":165,"context_line":"          \"2.2\": \"application/vnd.openstack-org.compute-v2+json\","},{"line_number":166,"context_line":"          \"2.4\": \"application/vnd.openstack-org.compute-v2+json\","},{"line_number":167,"context_line":"          \"latest\": \"application/vnd.openstack-org.compute-v2+json\","},{"line_number":168,"context_line":"          \"2.5\": \"application/vnd.openstack-org.compute-v2-experimental+json\","}],"source_content_type":"text/x-rst","patch_set":5,"id":"1ae5cdf2_06e25b9f","line":165,"in_reply_to":"1ae5cdf2_6873f84d","updated":"2014-06-20 20:57:27.000000000","message":"What I was trying to say is that typically the whole API doesn\u0027t go backwards incompatible at once.  But specific API requests will.  So I like the idea of signaling backwards incompatibility at the extension level, not at the level of the API as a whole.\n\nWith a single global microversion I\u0027m not sure what a major version bump means.  Maybe it\u0027s based on releases or maybe we do it every time there\u0027s a backwards incompatible change.  But I don\u0027t think it makes much sense to bump it for incompatible changes because it doesn\u0027t actually provide much useful information for a client.","commit_id":"8c74a075f997f9e52324ecfee1c5962ae48ff47d"},{"author":{"_account_id":6167,"name":"Ken\u0027ichi Ohmichi","email":"ken1ohmichi@gmail.com","username":"oomichi"},"change_message_id":"d03a7d3547472f819930185bab41b7201c62e641","unresolved":false,"context_lines":[{"line_number":162,"context_line":""},{"line_number":163,"context_line":"    {"},{"line_number":164,"context_line":"        \"versions\": {"},{"line_number":165,"context_line":"          \"2.2\": \"application/vnd.openstack-org.compute-v2+json\","},{"line_number":166,"context_line":"          \"2.4\": \"application/vnd.openstack-org.compute-v2+json\","},{"line_number":167,"context_line":"          \"latest\": \"application/vnd.openstack-org.compute-v2+json\","},{"line_number":168,"context_line":"          \"2.5\": \"application/vnd.openstack-org.compute-v2-experimental+json\","}],"source_content_type":"text/x-rst","patch_set":5,"id":"1ae5cdf2_1c850807","line":165,"in_reply_to":"1ae5cdf2_68c18a7f","updated":"2014-06-24 04:24:12.000000000","message":"@john\n\nDoes \"make incompatible changes go instep globally\" mean \"one increasement of a single global microversion covers all of incompatible changes such as v2 -\u003e v3\"?\n\nIf yes, that makes sense to me:)","commit_id":"8c74a075f997f9e52324ecfee1c5962ae48ff47d"},{"author":{"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},"change_message_id":"759451b4f4ddc6bc8f29328fadf965c79bf0cd9e","unresolved":false,"context_lines":[{"line_number":162,"context_line":""},{"line_number":163,"context_line":"    {"},{"line_number":164,"context_line":"        \"versions\": {"},{"line_number":165,"context_line":"          \"2.2\": \"application/vnd.openstack-org.compute-v2+json\","},{"line_number":166,"context_line":"          \"2.4\": \"application/vnd.openstack-org.compute-v2+json\","},{"line_number":167,"context_line":"          \"latest\": \"application/vnd.openstack-org.compute-v2+json\","},{"line_number":168,"context_line":"          \"2.5\": \"application/vnd.openstack-org.compute-v2-experimental+json\","}],"source_content_type":"text/x-rst","patch_set":5,"id":"1ae5cdf2_6873f84d","line":165,"in_reply_to":"1ae5cdf2_c5528e12","updated":"2014-06-20 13:58:22.000000000","message":"@Andrew, not quite understand \u0027Backwards incompatible API changes aren\u0027t happening at this level\u0027, or you mean \u0027Backwards compatible API\u0027?","commit_id":"8c74a075f997f9e52324ecfee1c5962ae48ff47d"},{"author":{"_account_id":6167,"name":"Ken\u0027ichi Ohmichi","email":"ken1ohmichi@gmail.com","username":"oomichi"},"change_message_id":"17d5abbfc1831114b2213625077805d30cdc7e4b","unresolved":false,"context_lines":[{"line_number":162,"context_line":""},{"line_number":163,"context_line":"    {"},{"line_number":164,"context_line":"        \"versions\": {"},{"line_number":165,"context_line":"          \"2.2\": \"application/vnd.openstack-org.compute-v2+json\","},{"line_number":166,"context_line":"          \"2.4\": \"application/vnd.openstack-org.compute-v2+json\","},{"line_number":167,"context_line":"          \"latest\": \"application/vnd.openstack-org.compute-v2+json\","},{"line_number":168,"context_line":"          \"2.5\": \"application/vnd.openstack-org.compute-v2-experimental+json\","}],"source_content_type":"text/x-rst","patch_set":5,"id":"1ae5cdf2_dee4cfe1","line":165,"in_reply_to":"1ae5cdf2_c5528e12","updated":"2014-06-20 08:37:54.000000000","message":"I agree that it is enough to increase the extension version only,  when backwards compatible changes.\n\nIt is simple and nice that the global version would be int.","commit_id":"8c74a075f997f9e52324ecfee1c5962ae48ff47d"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"da74a564f366f94746fbbafbfd46817ec12262e7","unresolved":false,"context_lines":[{"line_number":162,"context_line":""},{"line_number":163,"context_line":"    {"},{"line_number":164,"context_line":"        \"versions\": {"},{"line_number":165,"context_line":"          \"2.2\": \"application/vnd.openstack-org.compute-v2+json\","},{"line_number":166,"context_line":"          \"2.4\": \"application/vnd.openstack-org.compute-v2+json\","},{"line_number":167,"context_line":"          \"latest\": \"application/vnd.openstack-org.compute-v2+json\","},{"line_number":168,"context_line":"          \"2.5\": \"application/vnd.openstack-org.compute-v2-experimental+json\","}],"source_content_type":"text/x-rst","patch_set":5,"id":"1ae5cdf2_68c18a7f","line":165,"in_reply_to":"1ae5cdf2_c5528e12","updated":"2014-06-23 12:38:11.000000000","message":"well, I was trying to make incompatible changes go instep globally, but maybe that doesn\u0027t make any sense?","commit_id":"8c74a075f997f9e52324ecfee1c5962ae48ff47d"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"b1364bafbef6a9b53b3e97f82fdb6d1e2ec9bd60","unresolved":false,"context_lines":[{"line_number":166,"context_line":"          \"2.4\": \"application/vnd.openstack-org.compute-v2+json\","},{"line_number":167,"context_line":"          \"latest\": \"application/vnd.openstack-org.compute-v2+json\","},{"line_number":168,"context_line":"          \"2.5\": \"application/vnd.openstack-org.compute-v2-experimental+json\","},{"line_number":169,"context_line":"          \"3.1\": \"application/vnd.openstack-org.compute-v3-experimental+json\","},{"line_number":170,"context_line":"        },"},{"line_number":171,"context_line":"        \"resources\": {"},{"line_number":172,"context_line":"            \"/v2/servers\": {"}],"source_content_type":"text/x-rst","patch_set":5,"id":"1ae5cdf2_54746dce","line":169,"updated":"2014-06-18 14:46:05.000000000","message":"Is the point of this that the client should probe the server to see what the version is of the \"v2\" symbol, decide whether or not it can support it, and then either fail or continue with the request? That doesn\u0027t seem like microversions to me, that seems like \"discoverable regular versions\".\n\nWhat happens if we upgrade the API code in the middle of a session? The client thinks that the \"v2\" symbol means one thing, and the server\u0027s version changes to mean something else. If we go with a monotonic microversion, where the client is asking for \"2.132\" then that means the same thing now as it does an hour from now when the server gets upgraded.","commit_id":"8c74a075f997f9e52324ecfee1c5962ae48ff47d"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"da74a564f366f94746fbbafbfd46817ec12262e7","unresolved":false,"context_lines":[{"line_number":166,"context_line":"          \"2.4\": \"application/vnd.openstack-org.compute-v2+json\","},{"line_number":167,"context_line":"          \"latest\": \"application/vnd.openstack-org.compute-v2+json\","},{"line_number":168,"context_line":"          \"2.5\": \"application/vnd.openstack-org.compute-v2-experimental+json\","},{"line_number":169,"context_line":"          \"3.1\": \"application/vnd.openstack-org.compute-v3-experimental+json\","},{"line_number":170,"context_line":"        },"},{"line_number":171,"context_line":"        \"resources\": {"},{"line_number":172,"context_line":"            \"/v2/servers\": {"}],"source_content_type":"text/x-rst","patch_set":5,"id":"1ae5cdf2_ae223aa1","line":169,"in_reply_to":"1ae5cdf2_54746dce","updated":"2014-06-23 12:38:11.000000000","message":"well, I was taking the approach of client requesting a set of changes that are backwards compatible, but should it need a specific version, it can still check if its available. Its probably over complicating things, not sure.","commit_id":"8c74a075f997f9e52324ecfee1c5962ae48ff47d"},{"author":{"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},"change_message_id":"759451b4f4ddc6bc8f29328fadf965c79bf0cd9e","unresolved":false,"context_lines":[{"line_number":180,"context_line":"                \"status\": \"current\","},{"line_number":181,"context_line":"            },"},{"line_number":182,"context_line":"            \"/flavors\": {"},{"line_number":183,"context_line":"                \"versions\": [\"2.2\", \"2.4\", \"2.5\", \"3.1\"],"},{"line_number":184,"context_line":"                \"last_changed\": \"2014.2\""},{"line_number":185,"context_line":"                \"status\": \"current\","},{"line_number":186,"context_line":"            },"}],"source_content_type":"text/x-rst","patch_set":5,"id":"1ae5cdf2_88976444","line":183,"updated":"2014-06-20 13:58:22.000000000","message":"from 2.2 to 2.5 just a set of back compatible changes. We needn\u0027t keep them all. We just need keep the highest one in major version 2. Because there is meaningless for user request different version that only have some back compatible changes.","commit_id":"8c74a075f997f9e52324ecfee1c5962ae48ff47d"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"da74a564f366f94746fbbafbfd46817ec12262e7","unresolved":false,"context_lines":[{"line_number":180,"context_line":"                \"status\": \"current\","},{"line_number":181,"context_line":"            },"},{"line_number":182,"context_line":"            \"/flavors\": {"},{"line_number":183,"context_line":"                \"versions\": [\"2.2\", \"2.4\", \"2.5\", \"3.1\"],"},{"line_number":184,"context_line":"                \"last_changed\": \"2014.2\""},{"line_number":185,"context_line":"                \"status\": \"current\","},{"line_number":186,"context_line":"            },"}],"source_content_type":"text/x-rst","patch_set":5,"id":"1ae5cdf2_2e2e2a8d","line":183,"in_reply_to":"1ae5cdf2_88976444","updated":"2014-06-23 12:38:11.000000000","message":"The point here is to see when each extension has changed, and what things are available.\n\nGiven some are experimental, they can go away, etc.","commit_id":"8c74a075f997f9e52324ecfee1c5962ae48ff47d"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"a4fe549c72e0b973fca5c48619dc16e0d2867361","unresolved":false,"context_lines":[{"line_number":655,"context_line":"* The API wide microversion is increased when each development cycle."},{"line_number":656,"context_line":"  So the plugin microversion combination patch will be merged at the end"},{"line_number":657,"context_line":"  of each cycle. By avoiding frequent API wide version up, it makes the"},{"line_number":658,"context_line":"  client effect small."},{"line_number":659,"context_line":"* Clients can specify either API wide microversion or plugin microversion."},{"line_number":660,"context_line":"  In most use cases, clients will use API wide microversion because it is"},{"line_number":661,"context_line":"  easy to specify it. Plugin microversion will be used as \"experimental\""}],"source_content_type":"text/x-rst","patch_set":9,"id":"1ae5cdf2_e02ddc90","line":658,"updated":"2014-06-25 09:52:30.000000000","message":"As each plugin version up leads to API wide version up, frequency of API wide version up will be same as proposal 2 (right?). So how we will avoid frequent API wide version up?","commit_id":"9500fa70cbdeab2c87943ed2340712c3c6ddaf9a"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"f18bb214cb04a10ebf396658eb996638423b75c4","unresolved":false,"context_lines":[{"line_number":655,"context_line":"* The API wide microversion is increased when each development cycle."},{"line_number":656,"context_line":"  So the plugin microversion combination patch will be merged at the end"},{"line_number":657,"context_line":"  of each cycle. By avoiding frequent API wide version up, it makes the"},{"line_number":658,"context_line":"  client effect small."},{"line_number":659,"context_line":"* Clients can specify either API wide microversion or plugin microversion."},{"line_number":660,"context_line":"  In most use cases, clients will use API wide microversion because it is"},{"line_number":661,"context_line":"  easy to specify it. Plugin microversion will be used as \"experimental\""}],"source_content_type":"text/x-rst","patch_set":9,"id":"1ae5cdf2_e548818c","line":658,"in_reply_to":"1ae5cdf2_e02ddc90","updated":"2014-06-25 14:58:44.000000000","message":"This bit is out of date, so I deleted it. Its not true in the latest proposal, and added some things so it doesn\u0027t matter.","commit_id":"9500fa70cbdeab2c87943ed2340712c3c6ddaf9a"},{"author":{"_account_id":6167,"name":"Ken\u0027ichi Ohmichi","email":"ken1ohmichi@gmail.com","username":"oomichi"},"change_message_id":"77d01f09c75e29c9c482e20f8f7d8dd46b843c7e","unresolved":false,"context_lines":[{"line_number":53,"context_line":"* stable: will be available forever"},{"line_number":54,"context_line":""},{"line_number":55,"context_line":"* experimental: may be removed, at any time, and might be changed"},{"line_number":56,"context_line":"  in a backwards compatible way, as any time"},{"line_number":57,"context_line":""},{"line_number":58,"context_line":"In addition, each API version is also one of:"},{"line_number":59,"context_line":""}],"source_content_type":"text/x-rst","patch_set":10,"id":"1ae5cdf2_54a1e944","line":56,"updated":"2014-06-25 14:49:58.000000000","message":"s/compatible/incompatible/ ?","commit_id":"f5d95e9eb6a200c857c9f9695a864f4b573cb98c"},{"author":{"_account_id":6167,"name":"Ken\u0027ichi Ohmichi","email":"ken1ohmichi@gmail.com","username":"oomichi"},"change_message_id":"77d01f09c75e29c9c482e20f8f7d8dd46b843c7e","unresolved":false,"context_lines":[{"line_number":77,"context_line":"  We can assume json clients don\u0027t mind if they get extra data"},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"So the client will request the version major version it wants, so it"},{"line_number":80,"context_line":"get the data in a compatible form. But it can query the specific"},{"line_number":81,"context_line":"extension to find if that is value. Basically it request the \"latest\""},{"line_number":82,"context_line":"version, but the \"latest\" in a stream of backwards compatible versions."},{"line_number":83,"context_line":""}],"source_content_type":"text/x-rst","patch_set":10,"id":"1ae5cdf2_34b53d7e","line":80,"updated":"2014-06-25 14:49:58.000000000","message":"s/get/gets/","commit_id":"f5d95e9eb6a200c857c9f9695a864f4b573cb98c"},{"author":{"_account_id":6167,"name":"Ken\u0027ichi Ohmichi","email":"ken1ohmichi@gmail.com","username":"oomichi"},"change_message_id":"77d01f09c75e29c9c482e20f8f7d8dd46b843c7e","unresolved":false,"context_lines":[{"line_number":78,"context_line":""},{"line_number":79,"context_line":"So the client will request the version major version it wants, so it"},{"line_number":80,"context_line":"get the data in a compatible form. But it can query the specific"},{"line_number":81,"context_line":"extension to find if that is value. Basically it request the \"latest\""},{"line_number":82,"context_line":"version, but the \"latest\" in a stream of backwards compatible versions."},{"line_number":83,"context_line":""},{"line_number":84,"context_line":"Older clients, will continue to request the API in the same way they"}],"source_content_type":"text/x-rst","patch_set":10,"id":"1ae5cdf2_94a9b127","line":81,"updated":"2014-06-25 14:49:58.000000000","message":"s/request/requests/","commit_id":"f5d95e9eb6a200c857c9f9695a864f4b573cb98c"},{"author":{"_account_id":6167,"name":"Ken\u0027ichi Ohmichi","email":"ken1ohmichi@gmail.com","username":"oomichi"},"change_message_id":"77d01f09c75e29c9c482e20f8f7d8dd46b843c7e","unresolved":false,"context_lines":[{"line_number":162,"context_line":""},{"line_number":163,"context_line":"* client writers can tell which extensions have actually changed"},{"line_number":164,"context_line":""},{"line_number":165,"context_line":""},{"line_number":166,"context_line":"What does the version number mean?"},{"line_number":167,"context_line":"----------------------------------"},{"line_number":168,"context_line":""}],"source_content_type":"text/x-rst","patch_set":10,"id":"1ae5cdf2_b42dcdaa","line":165,"updated":"2014-06-25 14:49:58.000000000","message":"I agree to the above content.\nThe purpose is very clear, thanks.\n\nI have some questions/suggestion about the following:","commit_id":"f5d95e9eb6a200c857c9f9695a864f4b573cb98c"},{"author":{"_account_id":6167,"name":"Ken\u0027ichi Ohmichi","email":"ken1ohmichi@gmail.com","username":"oomichi"},"change_message_id":"77d01f09c75e29c9c482e20f8f7d8dd46b843c7e","unresolved":false,"context_lines":[{"line_number":175,"context_line":""},{"line_number":176,"context_line":"* X changes for any backwards incompatible changes to the API"},{"line_number":177,"context_line":""},{"line_number":178,"context_line":"* if Z \u003d \"beta\" then it is an experimental version"},{"line_number":179,"context_line":""},{"line_number":180,"context_line":"Any time any extensions changes, the global number increments, and the"},{"line_number":181,"context_line":"changed extension uses that new version as its version number."}],"source_content_type":"text/x-rst","patch_set":10,"id":"1ae5cdf2_4f7074a4","line":178,"updated":"2014-06-25 14:49:58.000000000","message":"Z \u003d \"beta\" is interesting idea.\n\nDuring 3.0.beta, I guess we can apply all of v3 changes(consistent interfaces) as one global version, right?","commit_id":"f5d95e9eb6a200c857c9f9695a864f4b573cb98c"},{"author":{"_account_id":6167,"name":"Ken\u0027ichi Ohmichi","email":"ken1ohmichi@gmail.com","username":"oomichi"},"change_message_id":"77d01f09c75e29c9c482e20f8f7d8dd46b843c7e","unresolved":false,"context_lines":[{"line_number":183,"context_line":"Now each extension has the following properties:"},{"line_number":184,"context_line":""},{"line_number":185,"context_line":"* supported_versions (full list of all versions, in order,"},{"line_number":186,"context_line":"  including experimental version, if any)"},{"line_number":187,"context_line":"* introduced"},{"line_number":188,"context_line":"* last_changed"},{"line_number":189,"context_line":"* deprecated (?)"}],"source_content_type":"text/x-rst","patch_set":10,"id":"1ae5cdf2_2fdc0846","line":186,"updated":"2014-06-25 14:49:58.000000000","message":"each microversion per extension is integer now, so can we mention it here?","commit_id":"f5d95e9eb6a200c857c9f9695a864f4b573cb98c"},{"author":{"_account_id":6167,"name":"Ken\u0027ichi Ohmichi","email":"ken1ohmichi@gmail.com","username":"oomichi"},"change_message_id":"77d01f09c75e29c9c482e20f8f7d8dd46b843c7e","unresolved":false,"context_lines":[{"line_number":184,"context_line":""},{"line_number":185,"context_line":"* supported_versions (full list of all versions, in order,"},{"line_number":186,"context_line":"  including experimental version, if any)"},{"line_number":187,"context_line":"* introduced"},{"line_number":188,"context_line":"* last_changed"},{"line_number":189,"context_line":"* deprecated (?)"},{"line_number":190,"context_line":""}],"source_content_type":"text/x-rst","patch_set":10,"id":"1ae5cdf2_afb73839","line":187,"updated":"2014-06-25 14:49:58.000000000","message":"I\u0027m not sure this \"introduced\" property.","commit_id":"f5d95e9eb6a200c857c9f9695a864f4b573cb98c"},{"author":{"_account_id":6167,"name":"Ken\u0027ichi Ohmichi","email":"ken1ohmichi@gmail.com","username":"oomichi"},"change_message_id":"77d01f09c75e29c9c482e20f8f7d8dd46b843c7e","unresolved":false,"context_lines":[{"line_number":185,"context_line":"* supported_versions (full list of all versions, in order,"},{"line_number":186,"context_line":"  including experimental version, if any)"},{"line_number":187,"context_line":"* introduced"},{"line_number":188,"context_line":"* last_changed"},{"line_number":189,"context_line":"* deprecated (?)"},{"line_number":190,"context_line":""},{"line_number":191,"context_line":"Globally we have the following properties:"}],"source_content_type":"text/x-rst","patch_set":10,"id":"1ae5cdf2_cf70040b","line":188,"updated":"2014-06-25 14:49:58.000000000","message":"This \"last_changed\" property has been removed since v3 because it was not updated and I think each extension microversion would be enough instead.","commit_id":"f5d95e9eb6a200c857c9f9695a864f4b573cb98c"},{"author":{"_account_id":6167,"name":"Ken\u0027ichi Ohmichi","email":"ken1ohmichi@gmail.com","username":"oomichi"},"change_message_id":"77d01f09c75e29c9c482e20f8f7d8dd46b843c7e","unresolved":false,"context_lines":[{"line_number":186,"context_line":"  including experimental version, if any)"},{"line_number":187,"context_line":"* introduced"},{"line_number":188,"context_line":"* last_changed"},{"line_number":189,"context_line":"* deprecated (?)"},{"line_number":190,"context_line":""},{"line_number":191,"context_line":"Globally we have the following properties:"},{"line_number":192,"context_line":""}],"source_content_type":"text/x-rst","patch_set":10,"id":"1ae5cdf2_0fbe6c64","line":189,"updated":"2014-06-25 14:49:58.000000000","message":"interesting, can we change back an extension microversion to \"0\" for representing the deprecated instead of another property?","commit_id":"f5d95e9eb6a200c857c9f9695a864f4b573cb98c"},{"author":{"_account_id":6167,"name":"Ken\u0027ichi Ohmichi","email":"ken1ohmichi@gmail.com","username":"oomichi"},"change_message_id":"77d01f09c75e29c9c482e20f8f7d8dd46b843c7e","unresolved":false,"context_lines":[{"line_number":215,"context_line":""},{"line_number":216,"context_line":"If you request a stable version, and our extensions does have that version"},{"line_number":217,"context_line":"you just get the stable version that was before the requested version. So"},{"line_number":218,"context_line":"it is matching on 2.A where A \u003e 123. So you request this:::"},{"line_number":219,"context_line":""},{"line_number":220,"context_line":"  Accept: application/vnd.openstack-org.compute-v2.123+json"},{"line_number":221,"context_line":""}],"source_content_type":"text/x-rst","patch_set":10,"id":"1ae5cdf2_6aaefe30","line":218,"updated":"2014-06-25 14:49:58.000000000","message":"I\u0027m not sure why we need this mechanism.\n\nI have concerns about this on both the implementation side and the test side.\n\nI think we need to keep each stable version(e.g. v2.22, v2.23 .. v2.123) and each version behavior should be stable and different from each other.\n\nThis mechanism will require us to keep old behaviors internally even if the changes are backwards compatible.\nThat would make the implementation complex.\nand we will need to run Tempest tests for each stable version in parallel for verifying the differences of behaviors. That needs a lot of cost for running Tempest at the gate.\n\nAs line90 mentioned, client should not break even if receiving a response including backwards compatible changes. So I think it is enough that clients can specify X part of version only.","commit_id":"f5d95e9eb6a200c857c9f9695a864f4b573cb98c"},{"author":{"_account_id":6167,"name":"Ken\u0027ichi Ohmichi","email":"ken1ohmichi@gmail.com","username":"oomichi"},"change_message_id":"77d01f09c75e29c9c482e20f8f7d8dd46b843c7e","unresolved":false,"context_lines":[{"line_number":228,"context_line":"  Accept: application/vnd.openstack-org.compute-v2.123.beta+json"},{"line_number":229,"context_line":""},{"line_number":230,"context_line":"If an extension doesn\u0027t implement that exact version, it responses with"},{"line_number":231,"context_line":"the error 406 (Not Acceptable)."},{"line_number":232,"context_line":""},{"line_number":233,"context_line":"If the client doesn\u0027t send an Accept header, then we return the default"},{"line_number":234,"context_line":"version, which is basically the version that would have been returned"}],"source_content_type":"text/x-rst","patch_set":10,"id":"1ae5cdf2_c5e0e528","line":231,"updated":"2014-06-25 14:49:58.000000000","message":"What does \"extra version\" mean here?\nexperimental version?","commit_id":"f5d95e9eb6a200c857c9f9695a864f4b573cb98c"},{"author":{"_account_id":6167,"name":"Ken\u0027ichi Ohmichi","email":"ken1ohmichi@gmail.com","username":"oomichi"},"change_message_id":"77d01f09c75e29c9c482e20f8f7d8dd46b843c7e","unresolved":false,"context_lines":[{"line_number":232,"context_line":""},{"line_number":233,"context_line":"If the client doesn\u0027t send an Accept header, then we return the default"},{"line_number":234,"context_line":"version, which is basically the version that would have been returned"},{"line_number":235,"context_line":"before we introduced this versioning."},{"line_number":236,"context_line":""},{"line_number":237,"context_line":"Versioning Examples"},{"line_number":238,"context_line":"-------------------"}],"source_content_type":"text/x-rst","patch_set":10,"id":"1ae5cdf2_e5b881ea","line":235,"updated":"2014-06-25 14:49:58.000000000","message":"This means the latest stable version in the smallest \"X\" as the default version, right?","commit_id":"f5d95e9eb6a200c857c9f9695a864f4b573cb98c"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"cf2239d60f5ddb4394685b77407639da8a66fa37","unresolved":false,"context_lines":[{"line_number":76,"context_line":"* ensure it gets the data it is looking for, in the format it expects."},{"line_number":77,"context_line":"  We can assume json clients don\u0027t mind if they get extra data"},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"So the client will request the version major version it wants, so it"},{"line_number":80,"context_line":"get the data in a compatible form. But it can query the specific"},{"line_number":81,"context_line":"extension to find if that is value. Basically it request the \"latest\""},{"line_number":82,"context_line":"version, but the \"latest\" in a stream of backwards compatible versions."}],"source_content_type":"text/x-rst","patch_set":11,"id":"1ae5cdf2_0f82e7c7","line":79,"updated":"2014-06-25 16:27:35.000000000","message":"s/version major version/major version/ ?","commit_id":"6613849d337d34716daa1cdd48e230421954e628"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"cf2239d60f5ddb4394685b77407639da8a66fa37","unresolved":false,"context_lines":[{"line_number":78,"context_line":""},{"line_number":79,"context_line":"So the client will request the version major version it wants, so it"},{"line_number":80,"context_line":"get the data in a compatible form. But it can query the specific"},{"line_number":81,"context_line":"extension to find if that is value. Basically it request the \"latest\""},{"line_number":82,"context_line":"version, but the \"latest\" in a stream of backwards compatible versions."},{"line_number":83,"context_line":""},{"line_number":84,"context_line":"Older clients, will continue to request the API in the same way they"}],"source_content_type":"text/x-rst","patch_set":11,"id":"1ae5cdf2_cf5e3f79","line":81,"updated":"2014-06-25 16:27:35.000000000","message":"s/value/valid/ ?\n\ns/request/requests/","commit_id":"6613849d337d34716daa1cdd48e230421954e628"},{"author":{"_account_id":5292,"name":"Christopher Yeoh","email":"cbkyeoh@gmail.com","username":"cyeoh-0"},"change_message_id":"254f1356cae7407eace60df33291c7d39ec65db8","unresolved":false,"context_lines":[{"line_number":140,"context_line":"Proposed change"},{"line_number":141,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":142,"context_line":""},{"line_number":143,"context_line":"There are two main proposals for micro visioning:"},{"line_number":144,"context_line":""},{"line_number":145,"context_line":"* version the whole API as one"},{"line_number":146,"context_line":""}],"source_content_type":"text/x-rst","patch_set":11,"id":"1ae5cdf2_d77ddfe8","line":143,"updated":"2014-06-26 04:06:02.000000000","message":"versioning even  :-)","commit_id":"6613849d337d34716daa1cdd48e230421954e628"},{"author":{"_account_id":5292,"name":"Christopher Yeoh","email":"cbkyeoh@gmail.com","username":"cyeoh-0"},"change_message_id":"254f1356cae7407eace60df33291c7d39ec65db8","unresolved":false,"context_lines":[{"line_number":173,"context_line":""},{"line_number":174,"context_line":"* Y changes for any backwards compatible changes to the API"},{"line_number":175,"context_line":""},{"line_number":176,"context_line":"* X changes for any backwards incompatible changes to the API"},{"line_number":177,"context_line":""},{"line_number":178,"context_line":"* if Z \u003d \"beta\" then it is an experimental version"},{"line_number":179,"context_line":""}],"source_content_type":"text/x-rst","patch_set":11,"id":"1ae5cdf2_2a405a34","line":176,"updated":"2014-06-26 04:06:02.000000000","message":"So my concern about this is the implication (I think) that backwards incompatible changes will be very very rare and back to the problem of big-bang. I don\u0027t think that will be the case. \n\nFor example for the first version of the tasks api we may want to implement it for server creation and and some actions, but perhaps not all cases where we have long running tasks. But staged in a series of improvements all of which will be backwards incompatible for the specific resource they are converting to tasks.\n\nThe second is to be able to gradually roll in the v3 API fixes. I think we\u0027ve established that we don\u0027t want to take the big-bang approach to these sorts of API changes. So bringing them in on a case by case basis was the strategy over the long term, each of which is possibly a backwards incompatible change (similar ones could be batched though).","commit_id":"6613849d337d34716daa1cdd48e230421954e628"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"cf2239d60f5ddb4394685b77407639da8a66fa37","unresolved":false,"context_lines":[{"line_number":175,"context_line":""},{"line_number":176,"context_line":"* X changes for any backwards incompatible changes to the API"},{"line_number":177,"context_line":""},{"line_number":178,"context_line":"* if Z \u003d \"beta\" then it is an experimental version"},{"line_number":179,"context_line":""},{"line_number":180,"context_line":"Any time any extensions changes, the global number increments, and the"},{"line_number":181,"context_line":"changed extension uses that new version as its version number."}],"source_content_type":"text/x-rst","patch_set":11,"id":"1ae5cdf2_2fea4374","line":178,"updated":"2014-06-25 16:27:35.000000000","message":"So 2.0.beta? That seems really odd to me.","commit_id":"6613849d337d34716daa1cdd48e230421954e628"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"cf2239d60f5ddb4394685b77407639da8a66fa37","unresolved":false,"context_lines":[{"line_number":178,"context_line":"* if Z \u003d \"beta\" then it is an experimental version"},{"line_number":179,"context_line":""},{"line_number":180,"context_line":"Any time any extensions changes, the global number increments, and the"},{"line_number":181,"context_line":"changed extension uses that new version as its version number."},{"line_number":182,"context_line":""},{"line_number":183,"context_line":"Now each extension has the following properties:"},{"line_number":184,"context_line":""}],"source_content_type":"text/x-rst","patch_set":11,"id":"1ae5cdf2_cf61df12","line":181,"updated":"2014-06-25 16:27:35.000000000","message":"I don\u0027t understand why extensions have versions. The point is to somehow indicate that if an extension has version x.y.z, equal to the global, then it must have \"just changed\" ? I don\u0027t see the point in that messaging. Why not just document what changed in each microversion on an API doc somewhere that the developers can read? What does it signal to a machine when the extension version matches (or doesn\u0027t match) that of the global version?","commit_id":"6613849d337d34716daa1cdd48e230421954e628"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"cf2239d60f5ddb4394685b77407639da8a66fa37","unresolved":false,"context_lines":[{"line_number":183,"context_line":"Now each extension has the following properties:"},{"line_number":184,"context_line":""},{"line_number":185,"context_line":"* supported_versions (full list of all versions, in order,"},{"line_number":186,"context_line":"  including experimental version, if any)"},{"line_number":187,"context_line":"* introduced"},{"line_number":188,"context_line":"* last_changed"},{"line_number":189,"context_line":"* deprecated (?)"}],"source_content_type":"text/x-rst","patch_set":11,"id":"1ae5cdf2_4f0a2f28","line":186,"updated":"2014-06-25 16:27:35.000000000","message":"Why? If we have a global monotonic counter, then I don\u0027t see why it matters what versions the extension was changed in.","commit_id":"6613849d337d34716daa1cdd48e230421954e628"},{"author":{"_account_id":5292,"name":"Christopher Yeoh","email":"cbkyeoh@gmail.com","username":"cyeoh-0"},"change_message_id":"254f1356cae7407eace60df33291c7d39ec65db8","unresolved":false,"context_lines":[{"line_number":213,"context_line":""},{"line_number":214,"context_line":"  Content-Type: application/vnd.openstack-org.compute-v2.123+json"},{"line_number":215,"context_line":""},{"line_number":216,"context_line":"If you request a stable version, and our extensions does have that version"},{"line_number":217,"context_line":"you just get the stable version that was before the requested version. So"},{"line_number":218,"context_line":"it is matching on 2.A where A \u003e 123. So you request this:::"},{"line_number":219,"context_line":""}],"source_content_type":"text/x-rst","patch_set":11,"id":"1ae5cdf2_77a5eb46","line":216,"updated":"2014-06-26 04:06:02.000000000","message":"is there a not missing from this sentence?","commit_id":"6613849d337d34716daa1cdd48e230421954e628"},{"author":{"_account_id":6167,"name":"Ken\u0027ichi Ohmichi","email":"ken1ohmichi@gmail.com","username":"oomichi"},"change_message_id":"598d85fa0c518c4701939d987c4077c012717781","unresolved":false,"context_lines":[{"line_number":215,"context_line":""},{"line_number":216,"context_line":"If you request a stable version, and our extensions does have that version"},{"line_number":217,"context_line":"you just get the stable version that was before the requested version. So"},{"line_number":218,"context_line":"it is matching on 2.A where A \u003e 123. So you request this:::"},{"line_number":219,"context_line":""},{"line_number":220,"context_line":"  Accept: application/vnd.openstack-org.compute-v2.123+json"},{"line_number":221,"context_line":""}],"source_content_type":"text/x-rst","patch_set":11,"id":"1ae5cdf2_df217b50","line":218,"updated":"2014-06-26 00:03:03.000000000","message":"copy\u0026paste my previous comment due to conflict to updating ;-)\n\nI\u0027m not sure why we need this mechanism.\n\nI have concerns about this on both the implementation side and the test side.\n\nI think we need to keep each stable version(e.g. v2.22, v2.23 .. v2.123) and each version behavior should be stable and different from each other.\n\nThis mechanism will require us to keep old behaviors internally even if the changes are backwards compatible. That would make the implementation complex. and we will need to run Tempest tests for each stable version in parallel for verifying the differences of behaviors. That needs a lot of cost for running Tempest at the gate.\n\nAs line90 mentioned, client should not break even if receiving a response including backwards compatible changes. So I think it is enough that clients can specify X part of version only.","commit_id":"6613849d337d34716daa1cdd48e230421954e628"},{"author":{"_account_id":6167,"name":"Ken\u0027ichi Ohmichi","email":"ken1ohmichi@gmail.com","username":"oomichi"},"change_message_id":"598d85fa0c518c4701939d987c4077c012717781","unresolved":false,"context_lines":[{"line_number":232,"context_line":""},{"line_number":233,"context_line":"If the client doesn\u0027t send an Accept header, then we return the default"},{"line_number":234,"context_line":"version, which is basically the version that would have been returned"},{"line_number":235,"context_line":"before we introduced this versioning."},{"line_number":236,"context_line":""},{"line_number":237,"context_line":"Versioning Examples"},{"line_number":238,"context_line":"-------------------"}],"source_content_type":"text/x-rst","patch_set":11,"id":"1ae5cdf2_9f87f311","line":235,"updated":"2014-06-26 00:03:03.000000000","message":"I think if we get a consensus about the above default behavior, we can start v2.1 developemt(https://review.openstack.org/#/c/84695/), right?","commit_id":"6613849d337d34716daa1cdd48e230421954e628"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"cf2239d60f5ddb4394685b77407639da8a66fa37","unresolved":false,"context_lines":[{"line_number":257,"context_line":"that means the client will have to always explicitly request the version"},{"line_number":258,"context_line":"it is testing, such as:::"},{"line_number":259,"context_line":""},{"line_number":260,"context_line":"  Accept: application/vnd.openstack-org.compute-v2.123.beta+json"},{"line_number":261,"context_line":""},{"line_number":262,"context_line":"Note that the beta version must be backwards compatible with the last stable"},{"line_number":263,"context_line":"version of that major version, so in this case 2.0.0. But any following stable"}],"source_content_type":"text/x-rst","patch_set":11,"id":"1ae5cdf2_12568c06","line":260,"updated":"2014-06-25 16:27:35.000000000","message":"Why not add +exp to get experimental things? 2.123.beta just seems strange to me, even if it\u0027s just for what the parsing code would look like.","commit_id":"6613849d337d34716daa1cdd48e230421954e628"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"cf2239d60f5ddb4394685b77407639da8a66fa37","unresolved":false,"context_lines":[{"line_number":304,"context_line":"all the fixes to that extension."},{"line_number":305,"context_line":""},{"line_number":306,"context_line":"Introducing what used to be v3"},{"line_number":307,"context_line":"********************************"},{"line_number":308,"context_line":""},{"line_number":309,"context_line":"v3 is a backwards incompatible change, that could be made available as an"},{"line_number":310,"context_line":"experimental API."}],"source_content_type":"text/x-rst","patch_set":11,"id":"1ae5cdf2_3228e832","line":307,"updated":"2014-06-25 16:27:35.000000000","message":"Do you mean what is in the current tree as \u0027v3\u0027 or a future hypothetical incompatible API change? If the latter, then I think this should be worded differently. This makes it sound like you\u0027re proposing exposing what is currently /v3 as a 3.0.0 microversion.","commit_id":"6613849d337d34716daa1cdd48e230421954e628"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"cf2239d60f5ddb4394685b77407639da8a66fa37","unresolved":false,"context_lines":[{"line_number":323,"context_line":""},{"line_number":324,"context_line":"  Accept: application/vnd.openstack-org.compute-v3+json"},{"line_number":325,"context_line":""},{"line_number":326,"context_line":"What happens to v2 after we have v3?"},{"line_number":327,"context_line":"************************************"},{"line_number":328,"context_line":""},{"line_number":329,"context_line":"While this is not a property that is required by the above versioning"}],"source_content_type":"text/x-rst","patch_set":11,"id":"1ae5cdf2_12dccc45","line":326,"updated":"2014-06-25 16:27:35.000000000","message":"I think these would make this clearer:\n\ns/v2/2.x.x/\n\ns/v3/a new 3.x.x/","commit_id":"6613849d337d34716daa1cdd48e230421954e628"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"cf2239d60f5ddb4394685b77407639da8a66fa37","unresolved":false,"context_lines":[{"line_number":339,"context_line":"version of the API in one \"big bang\"."},{"line_number":340,"context_line":""},{"line_number":341,"context_line":"It is very possible that we choose not ever release the version that is"},{"line_number":342,"context_line":"currently called v3, and keep only v2.x, but that is a valid step forward"},{"line_number":343,"context_line":"with this proposed version scheme. We could create a future versions of v3"},{"line_number":344,"context_line":"that proposes a radically different API, and that is fine within this"},{"line_number":345,"context_line":"proposed scheme."}],"source_content_type":"text/x-rst","patch_set":11,"id":"1ae5cdf2_52cc948a","line":342,"updated":"2014-06-25 16:27:35.000000000","message":"I think your eponymous \"doctrine\" says we won\u0027t, so I\u0027d snip this out and make this paragraph about what will happen if/when we ever introduce a radically different API.","commit_id":"6613849d337d34716daa1cdd48e230421954e628"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"cf2239d60f5ddb4394685b77407639da8a66fa37","unresolved":false,"context_lines":[{"line_number":358,"context_line":"Checking the servers latest version would tell you if the new extension"},{"line_number":359,"context_line":"is happening."},{"line_number":360,"context_line":""},{"line_number":361,"context_line":"Modifying an exiting extension"},{"line_number":362,"context_line":"******************************"},{"line_number":363,"context_line":""},{"line_number":364,"context_line":"If it is just a bug fix, and has no client impact (no extra values,"}],"source_content_type":"text/x-rst","patch_set":11,"id":"1ae5cdf2_527ad425","line":361,"updated":"2014-06-25 16:27:35.000000000","message":"s/exiting/existing/","commit_id":"6613849d337d34716daa1cdd48e230421954e628"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"cf2239d60f5ddb4394685b77407639da8a66fa37","unresolved":false,"context_lines":[{"line_number":363,"context_line":""},{"line_number":364,"context_line":"If it is just a bug fix, and has no client impact (no extra values,"},{"line_number":365,"context_line":"and no extra features), simply change 2.4 to 2.4.1 on the specific"},{"line_number":366,"context_line":"extension."},{"line_number":367,"context_line":""},{"line_number":368,"context_line":"Any backwards compatible modification, you bump 2.4 to 2.5 and use that"},{"line_number":369,"context_line":"version to start activating that modification."}],"source_content_type":"text/x-rst","patch_set":11,"id":"1ae5cdf2_329b8867","line":366,"updated":"2014-06-25 16:27:35.000000000","message":"You said above that Z is for stable-branch changes only, so this should be 2.4 -\u003e 2.5 ?","commit_id":"6613849d337d34716daa1cdd48e230421954e628"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"cf2239d60f5ddb4394685b77407639da8a66fa37","unresolved":false,"context_lines":[{"line_number":371,"context_line":"If the client requests an older version, you should work as you did"},{"line_number":372,"context_line":"before."},{"line_number":373,"context_line":""},{"line_number":374,"context_line":"Modifying an exiting experimental version"},{"line_number":375,"context_line":"*****************************************"},{"line_number":376,"context_line":""},{"line_number":377,"context_line":"If a client requests a specific experimental version, it should never"}],"source_content_type":"text/x-rst","patch_set":11,"id":"1ae5cdf2_f2b760d5","line":374,"updated":"2014-06-25 16:27:35.000000000","message":"s/exiting/existing/","commit_id":"6613849d337d34716daa1cdd48e230421954e628"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"cf2239d60f5ddb4394685b77407639da8a66fa37","unresolved":false,"context_lines":[{"line_number":418,"context_line":"so if you make changes, you always delete the old one, and create a new"},{"line_number":419,"context_line":"merged proposal. This will hurt the testing a little, but could work."},{"line_number":420,"context_line":""},{"line_number":421,"context_line":"Deprecating an exiting extension"},{"line_number":422,"context_line":"********************************"},{"line_number":423,"context_line":""},{"line_number":424,"context_line":"Should we want to remove an extension we can deprecate it."}],"source_content_type":"text/x-rst","patch_set":11,"id":"1ae5cdf2_b2bdd8b3","line":421,"updated":"2014-06-25 16:27:35.000000000","message":"s/exiting/existing/","commit_id":"6613849d337d34716daa1cdd48e230421954e628"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"cf2239d60f5ddb4394685b77407639da8a66fa37","unresolved":false,"context_lines":[{"line_number":513,"context_line":"* Out of scope of this specification for both proposals are issues"},{"line_number":514,"context_line":"  around of discovery as they would work the same way with both."},{"line_number":515,"context_line":""},{"line_number":516,"context_line":"Proposal 1 - Every plugin is versioned"},{"line_number":517,"context_line":"**************************************"},{"line_number":518,"context_line":""},{"line_number":519,"context_line":"With the V3 API framework everything is a plugin and has its own"}],"source_content_type":"text/x-rst","patch_set":11,"id":"1ae5cdf2_d2026471","line":516,"updated":"2014-06-25 16:27:35.000000000","message":"-1","commit_id":"6613849d337d34716daa1cdd48e230421954e628"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"cf2239d60f5ddb4394685b77407639da8a66fa37","unresolved":false,"context_lines":[{"line_number":528,"context_line":"  use new features because they need to check each plugin microversion"},{"line_number":529,"context_line":"  before sending a request."},{"line_number":530,"context_line":""},{"line_number":531,"context_line":"Proposal 2 - API wide microversion"},{"line_number":532,"context_line":"**********************************"},{"line_number":533,"context_line":""},{"line_number":534,"context_line":"There is a single monotonically incrementing microversion which"}],"source_content_type":"text/x-rst","patch_set":11,"id":"1ae5cdf2_12fdac6e","line":531,"updated":"2014-06-25 16:27:35.000000000","message":"+2","commit_id":"6613849d337d34716daa1cdd48e230421954e628"},{"author":{"_account_id":6167,"name":"Ken\u0027ichi Ohmichi","email":"ken1ohmichi@gmail.com","username":"oomichi"},"change_message_id":"598d85fa0c518c4701939d987c4077c012717781","unresolved":false,"context_lines":[{"line_number":528,"context_line":"  use new features because they need to check each plugin microversion"},{"line_number":529,"context_line":"  before sending a request."},{"line_number":530,"context_line":""},{"line_number":531,"context_line":"Proposal 2 - API wide microversion"},{"line_number":532,"context_line":"**********************************"},{"line_number":533,"context_line":""},{"line_number":534,"context_line":"There is a single monotonically incrementing microversion which"}],"source_content_type":"text/x-rst","patch_set":11,"id":"1ae5cdf2_7f64e7b2","line":531,"in_reply_to":"1ae5cdf2_12fdac6e","updated":"2014-06-26 00:03:03.000000000","message":"-1 due to the following cons.","commit_id":"6613849d337d34716daa1cdd48e230421954e628"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"cf2239d60f5ddb4394685b77407639da8a66fa37","unresolved":false,"context_lines":[{"line_number":581,"context_line":"add new feature 4 to plugin B (206)   apply 206"},{"line_number":582,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d   \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":583,"context_line":""},{"line_number":584,"context_line":"Proposal 3 - The combination of both microversions"},{"line_number":585,"context_line":"**************************************************"},{"line_number":586,"context_line":""},{"line_number":587,"context_line":"Described above."}],"source_content_type":"text/x-rst","patch_set":11,"id":"1ae5cdf2_92f0dc92","line":584,"updated":"2014-06-25 16:27:35.000000000","message":"-1","commit_id":"6613849d337d34716daa1cdd48e230421954e628"}]}