)]}'
{"reference/projects.yaml":[{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"8359d1a842ac8d7f4852690be90daabb54e07973","unresolved":false,"context_lines":[{"line_number":1705,"context_line":"        - stable:follows-policy"},{"line_number":1706,"context_line":"        - assert:supports-upgrade"},{"line_number":1707,"context_line":"        - assert:follows-standard-deprecation"},{"line_number":1708,"context_line":"        - assert:supports-api-interoperability"},{"line_number":1709,"context_line":"    ironic-inspector:"},{"line_number":1710,"context_line":"      repos:"},{"line_number":1711,"context_line":"        - openstack/ironic-inspector"}],"source_content_type":"text/x-yaml","patch_set":5,"id":"ff0f0b1f_fbc420f7","line":1708,"updated":"2017-05-22 17:54:14.000000000","message":"We usually apply the tag to project teams in a separate commit.","commit_id":"ee7b9304dc04097587ca31af7ec7ff7b0239c368"}],"reference/tags/assert_supports-api-compatibility.rst":[{"author":{"_account_id":8099,"name":"Graham Hayes","email":"gr@ham.ie","username":"graham"},"change_message_id":"eaf534876bd8906622d27f1af30b09ddefbe2e69","unresolved":false,"context_lines":[{"line_number":42,"context_line":""},{"line_number":43,"context_line":".. _API change guidelines: http://specs.openstack.org/openstack/api-wg/guidelines/evaluating_api_changes.html"},{"line_number":44,"context_line":""},{"line_number":45,"context_line":"#. The projects API uses a versioning scheme, like `microversions`_, to ensure"},{"line_number":46,"context_line":"   that any new features or other changes to the API are both explicit and"},{"line_number":47,"context_line":"   discoverable."},{"line_number":48,"context_line":""},{"line_number":49,"context_line":".. _microversions: http://specs.openstack.org/openstack/api-wg/guidelines/microversion_specification.html"},{"line_number":50,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"ba5201f7_9fca6a6d","line":47,"range":{"start_line":45,"start_character":0,"end_line":47,"end_character":16},"updated":"2017-01-09 18:33:42.000000000","message":"I think \"Uses a discovery mechanism\"  (that could be a versioning scheme) is better.\n\nWe (in designate at least) have some features that are toggleable, and some that are controlled by policy.\n\nI would prefer for us to have a \u0027\u003cendpoint\u003e/v\u003cversion\u003e/capabilities\u0027 endpoint that can show what is availible (and the policy allows).\n\nPersonally, for microversions, this is not the case - I know that i have version 200, therefore I *might* have access to $FEATURE.\n\nAs a result I don\u0027t think we should be tying ourselves to versioning as a way to show features, or other changes.","commit_id":"14a05e3052f2091a1f32d772d1767a31eb586cb4"},{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"c0fea09c80ffeefbbf5274f53e9e4de56b68ccd4","unresolved":false,"context_lines":[{"line_number":12,"context_line":""},{"line_number":13,"context_line":"This tag is part of the assert category of tags, which are assertions"},{"line_number":14,"context_line":"made by the project team themselves about their maturity. One such assertion"},{"line_number":15,"context_line":"(or self-imposed contract) is about the stability of the api."},{"line_number":16,"context_line":""},{"line_number":17,"context_line":"The \"assert:supports-api-compatibility\" tag asserts that the project will follow"},{"line_number":18,"context_line":"the API change guidelines and that they will not change an API in a way that"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7a3c09a3_7c05290f","line":15,"updated":"2017-01-17 20:24:07.000000000","message":"nit: API* to be consistent with other usage in the document.","commit_id":"e52f92132b0cd2a6d30d4f4bbc93c6e156a4c63d"},{"author":{"_account_id":5196,"name":"Matthew Treinish","email":"mtreinish@kortar.org","username":"treinish"},"change_message_id":"005ca2fba4b311db8b9bb9cc63484fcddc2fb23f","unresolved":false,"context_lines":[{"line_number":12,"context_line":""},{"line_number":13,"context_line":"This tag is part of the assert category of tags, which are assertions"},{"line_number":14,"context_line":"made by the project team themselves about their maturity. One such assertion"},{"line_number":15,"context_line":"(or self-imposed contract) is about the stability of the api."},{"line_number":16,"context_line":""},{"line_number":17,"context_line":"The \"assert:supports-api-compatibility\" tag asserts that the project will follow"},{"line_number":18,"context_line":"the API change guidelines and that they will not change an API in a way that"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7a3c09a3_10083628","line":15,"in_reply_to":"7a3c09a3_7c05290f","updated":"2017-01-18 23:57:43.000000000","message":"Done","commit_id":"e52f92132b0cd2a6d30d4f4bbc93c6e156a4c63d"},{"author":{"_account_id":308,"name":"Thierry Carrez","email":"thierry@openstack.org","username":"ttx"},"change_message_id":"0e1870f3423d7e8cd1d7764f2a78918fb887764c","unresolved":false,"context_lines":[{"line_number":15,"context_line":"(or self-imposed contract) is about the stability of the api."},{"line_number":16,"context_line":""},{"line_number":17,"context_line":"The \"assert:supports-api-compatibility\" tag asserts that the project will follow"},{"line_number":18,"context_line":"the API change guidelines and that they will not change an API in a way that"},{"line_number":19,"context_line":"will break existing users of an API."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"Application to current projects"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7a3c09a3_c2001604","line":18,"updated":"2017-01-17 11:17:46.000000000","message":"\"change\" -\u003e \"change (or remove)\" ?","commit_id":"e52f92132b0cd2a6d30d4f4bbc93c6e156a4c63d"},{"author":{"_account_id":5196,"name":"Matthew Treinish","email":"mtreinish@kortar.org","username":"treinish"},"change_message_id":"005ca2fba4b311db8b9bb9cc63484fcddc2fb23f","unresolved":false,"context_lines":[{"line_number":15,"context_line":"(or self-imposed contract) is about the stability of the api."},{"line_number":16,"context_line":""},{"line_number":17,"context_line":"The \"assert:supports-api-compatibility\" tag asserts that the project will follow"},{"line_number":18,"context_line":"the API change guidelines and that they will not change an API in a way that"},{"line_number":19,"context_line":"will break existing users of an API."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"Application to current projects"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7a3c09a3_5012be59","line":18,"in_reply_to":"7a3c09a3_c2001604","updated":"2017-01-18 23:57:43.000000000","message":"Sure","commit_id":"e52f92132b0cd2a6d30d4f4bbc93c6e156a4c63d"},{"author":{"_account_id":8099,"name":"Graham Hayes","email":"gr@ham.ie","username":"graham"},"change_message_id":"efff9bed81337775caf251d379da0d074fbb1fa6","unresolved":false,"context_lines":[{"line_number":42,"context_line":""},{"line_number":43,"context_line":".. _API change guidelines: http://specs.openstack.org/openstack/api-wg/guidelines/evaluating_api_changes.html"},{"line_number":44,"context_line":""},{"line_number":45,"context_line":"#. The projects API uses a versioning scheme, like `microversions`_, to ensure"},{"line_number":46,"context_line":"   that any new features or other changes to the API are both explicit and"},{"line_number":47,"context_line":"   discoverable."},{"line_number":48,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"7a3c09a3_abe1d72b","line":45,"updated":"2017-01-18 15:00:20.000000000","message":"I think \"Uses a discovery mechanism\"  (that could be a versioning scheme) is better.\n\nWe (in designate at least) have some features that are toggleable, and some that are controlled by policy.\n\nI would prefer for us to have a \u0027\u003cendpoint\u003e/v\u003cversion\u003e/capabilities\u0027  (or any other term) endpoint that can show what is available (and the policy allows).\n\nPersonally, I don\u0027t think microversions provide this - I know that i have version 200, therefore I *might* have access to $FEATURE.\nAs a result I don\u0027t think we should be tying ourselves to versioning as a way to show features, or other changes.","commit_id":"e52f92132b0cd2a6d30d4f4bbc93c6e156a4c63d"},{"author":{"_account_id":5196,"name":"Matthew Treinish","email":"mtreinish@kortar.org","username":"treinish"},"change_message_id":"005ca2fba4b311db8b9bb9cc63484fcddc2fb23f","unresolved":false,"context_lines":[{"line_number":42,"context_line":""},{"line_number":43,"context_line":".. _API change guidelines: http://specs.openstack.org/openstack/api-wg/guidelines/evaluating_api_changes.html"},{"line_number":44,"context_line":""},{"line_number":45,"context_line":"#. The projects API uses a versioning scheme, like `microversions`_, to ensure"},{"line_number":46,"context_line":"   that any new features or other changes to the API are both explicit and"},{"line_number":47,"context_line":"   discoverable."},{"line_number":48,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"7a3c09a3_504abe28","line":45,"in_reply_to":"7a3c09a3_abe1d72b","updated":"2017-01-18 23:57:43.000000000","message":"What you\u0027re referring to is actually a different thing. While you can use that discovery as versioning, this point is specifically about evolving the api in a way that doesn\u0027t break existing users. This isn\u0027t talking about optional feature discovery, just how api changes are exposed to users.\n\nWhat you\u0027re describing can be used for this, that is essentially how projects used extensions in a pre-microversion world. But, I would caution against doing that because it grows to be unwieldy. In my experience you want to keep optional feature discovery separate from versioning since they are related but different things.\n\nFor this tag I don\u0027t think we want to discuss optional feature discovery, it might be a future thing (or a separate tag) but for right now I think the intent is just to keep it about stable apis that users can rely on.","commit_id":"e52f92132b0cd2a6d30d4f4bbc93c6e156a4c63d"},{"author":{"_account_id":17716,"name":"Luz Cazares","email":"luz.cazares@intel.com","username":"luzcazares"},"change_message_id":"1675d83e85c6a17fd99989fef543b6053e528066","unresolved":false,"context_lines":[{"line_number":15,"context_line":"(or self-imposed contract) is about the stability of the API."},{"line_number":16,"context_line":""},{"line_number":17,"context_line":"The \"assert:supports-api-compatibility\" tag asserts that the project will follow"},{"line_number":18,"context_line":"the API change guidelines and that they will not change (or remove) an API in a"},{"line_number":19,"context_line":"way that will break existing users of an API."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"Application to current projects"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a3905b3_34fc913d","line":18,"range":{"start_line":18,"start_character":57,"end_line":18,"end_character":66},"updated":"2017-01-23 20:22:34.000000000","message":"about the word \"remove\" isn\u0027t it covered by \"follows-standard-deprecation\" tag? if not, should it be stated how is it diffent (probably scope)?","commit_id":"c93ed1cccb71cdaeb2cf6261263bd75897880a79"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"d149a054b82b7ef1c0194841386dfa5a3d519fa0","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"1f013ff3_ab09ec2c","line":50,"updated":"2017-05-16 19:01:27.000000000","message":"The \"Tag application process\" and \"Deprecation\" sections are missing here.\n\nI\u0027m particularly interested in who is going to certify this. Is the list of projects with this tag managed by the API working group, or the TC directly? If it\u0027s the API working group, do we want the name to reflect that (using something like api:supports-compatibility to namespace it under that team)?","commit_id":"c93ed1cccb71cdaeb2cf6261263bd75897880a79"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"262ef87f53bffb32b033aa0210985a1dd348531b","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"ff0f0b1f_da5b2552","line":50,"in_reply_to":"1f013ff3_ab09ec2c","updated":"2017-05-17 11:25:45.000000000","message":"Since this is an \u0027asserts\u0027 style tag, does this need certification? My understanding was an asserts tag is something the project chooses and then polices themselves?\n\nAnyone attempting to certify that a project is maintaining interoperability/stability/compatibility needs to be very familiar with the project\u0027s API, and I\u0027m not sure anyone besides project members have that kind of time/interest.","commit_id":"c93ed1cccb71cdaeb2cf6261263bd75897880a79"}],"reference/tags/assert_supports-api-interoperability.rst":[{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"541ad3b96243d62484af4cb6d754e8324cb87f11","unresolved":false,"context_lines":[{"line_number":15,"context_line":"(or self-imposed contract) is about the interoperability of the API. In this"},{"line_number":16,"context_line":"context interoperability is a combination of an API that\u0027s both stable and compatible."},{"line_number":17,"context_line":""},{"line_number":18,"context_line":"The \"assert:supports-api-interoperability\" tag asserts that the project will follow the API interoperability guidelines and that they will not change (or"},{"line_number":19,"context_line":"remove) an API in a way that will break existing users of an API."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"Application to current projects"}],"source_content_type":"text/x-rst","patch_set":5,"id":"ff0f0b1f_259dd5bb","line":18,"updated":"2017-05-22 16:41:47.000000000","message":"line length","commit_id":"ee7b9304dc04097587ca31af7ec7ff7b0239c368"},{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"43993a54009747d460537e2ed90ffaf6d129bec4","unresolved":false,"context_lines":[{"line_number":41,"context_line":"   REST API"},{"line_number":42,"context_line":"#. The projects API uses a versioning scheme, like `microversions`_, to ensure"},{"line_number":43,"context_line":"   that any new features or other changes to the API are both explicit and"},{"line_number":44,"context_line":"   discoverable."},{"line_number":45,"context_line":"#. There are branchless API tests run on every commit to ensure that the API"},{"line_number":46,"context_line":"   doesn\u0027t change between release boundaries."},{"line_number":47,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"df140735_86bbe60c","line":44,"updated":"2017-06-07 19:32:56.000000000","message":"Just double checking here, but this doesn\u0027t *require* projects to implement microversions to assert this tag, does it?","commit_id":"ee7b9304dc04097587ca31af7ec7ff7b0239c368"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"919e38458852e6481d3e6b9a406ed6f9e0ff1024","unresolved":false,"context_lines":[{"line_number":41,"context_line":"   REST API"},{"line_number":42,"context_line":"#. The projects API uses a versioning scheme, like `microversions`_, to ensure"},{"line_number":43,"context_line":"   that any new features or other changes to the API are both explicit and"},{"line_number":44,"context_line":"   discoverable."},{"line_number":45,"context_line":"#. There are branchless API tests run on every commit to ensure that the API"},{"line_number":46,"context_line":"   doesn\u0027t change between release boundaries."},{"line_number":47,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"bf091321_11e3a935","line":44,"in_reply_to":"df140735_86bbe60c","updated":"2017-06-08 10:07:59.000000000","message":"That\u0027s correct. Microversions are not required but some kind of versioning scheme is. In the guideline it says:\n\n\"This document does not address versioning, however the only mechanism in active use in OpenStack that has been demonstrated to work for the goals described here are microversions.\"\n\nA translation of that might be something like \"you don\u0027t have to use microversions, but if you do they will provide you with tooling that allows you to more easily make changes in features without abandoning backwards compatibility or interoperability between clouds\" (because of the effective content-negotiation that the version header provides).","commit_id":"ee7b9304dc04097587ca31af7ec7ff7b0239c368"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"8359d1a842ac8d7f4852690be90daabb54e07973","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":5,"id":"ff0f0b1f_1b4eb496","line":50,"updated":"2017-05-22 17:54:14.000000000","message":"This is still missing the last few sections of the tag definition template that cover applying and deprecating the tag.","commit_id":"ee7b9304dc04097587ca31af7ec7ff7b0239c368"}]}