)]}'
{"reference/projects.yaml":[{"author":{"_account_id":308,"name":"Thierry Carrez","email":"thierry@openstack.org","username":"ttx"},"change_message_id":"c87a9cd47b947297154a753fa098d771b960753d","unresolved":false,"context_lines":[{"line_number":4543,"context_line":"        - vulnerability:managed"},{"line_number":4544,"context_line":"        - stable:follows-policy"},{"line_number":4545,"context_line":"        - assert:follows-standard-deprecation"},{"line_number":4546,"context_line":"        - assert:never-breaks-compat"},{"line_number":4547,"context_line":"        - assert:supports-upgrade"},{"line_number":4548,"context_line":"        - assert:supports-rolling-upgrade"},{"line_number":4549,"context_line":"    swift-bench:"}],"source_content_type":"text/x-yaml","patch_set":1,"id":"1a1ced50_08d80c53","line":4546,"updated":"2017-03-17 10:26:45.000000000","message":"While I agree that Swift meets the conditions and probably would want to assert such a tag, I\u0027d rather make sure they are the ones making the assertion (so that it\u0027s binding).","commit_id":"fd731eb4641a1fa05b22959c47760fb7f0e3da28"}],"reference/tags/assert_never-breaks-compat.rst":[{"author":{"_account_id":308,"name":"Thierry Carrez","email":"thierry@openstack.org","username":"ttx"},"change_message_id":"c87a9cd47b947297154a753fa098d771b960753d","unresolved":false,"context_lines":[{"line_number":43,"context_line":"Project teams can apply this tag to services or libraries that they produce to"},{"line_number":44,"context_line":"assert that they will never break backwards compatibility. More specifically,"},{"line_number":45,"context_line":"that means:"},{"line_number":46,"context_line":""},{"line_number":47,"context_line":"#. Features, APIs or configuration options, once released, will continue to"},{"line_number":48,"context_line":"   work in perpetuity."},{"line_number":49,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a1ced50_e82bb031","line":46,"updated":"2017-03-17 10:26:45.000000000","message":"I would add that you have to abide to the requirements of the standard-deprecation-policy (basically making sure never-breaks-compat tag is additional requirements, not alternative requirements)","commit_id":"fd731eb4641a1fa05b22959c47760fb7f0e3da28"},{"author":{"_account_id":308,"name":"Thierry Carrez","email":"thierry@openstack.org","username":"ttx"},"change_message_id":"3fd7a1e371677005ad26dae0c992f2ae4d42e97c","unresolved":false,"context_lines":[{"line_number":29,"context_line":"Rationale"},{"line_number":30,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":31,"context_line":""},{"line_number":32,"context_line":"Users or a library or service need to know whether they can count on features"},{"line_number":33,"context_line":"of the API over time. While semver is a popular mechanism to communicate to"},{"line_number":34,"context_line":"a user when a breaking change has been made, some projects choose to make a"},{"line_number":35,"context_line":"stronger guarantee to their users that they will never make a release with"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1a1ced50_72e661b1","line":32,"range":{"start_line":32,"start_character":6,"end_line":32,"end_character":8},"updated":"2017-03-21 11:15:21.000000000","message":"\"of\"","commit_id":"378c307238933e76cce09b9bae9b7c058966f9e8"},{"author":{"_account_id":6159,"name":"Flavio Percoco Premoli","display_name":"flaper87","email":"flavio.percoco@flyrlabs.com","username":"flaper87"},"change_message_id":"53ad29d6d511f291dd9529e7405704bfeb5b1204","unresolved":false,"context_lines":[{"line_number":69,"context_line":""},{"line_number":70,"context_line":"The goal of the assertion is to not break users, not merely to follow a set of"},{"line_number":71,"context_line":"instructions. Additionally, never-breaks-compat is intended to be a stricter"},{"line_number":72,"context_line":"superset of standard-deprecation-policy."}],"source_content_type":"text/x-rst","patch_set":2,"id":"1a1ced50_94f10004","line":72,"updated":"2017-03-21 14:28:42.000000000","message":"mmhh, I think I might be missing something because after reading this tag\u0027s definition it sounds to me like this tag is actually incompatible with the `standard-deprecation-policy` one. That is to say, you can have either but not both. Is that correct? Where\u0027s my english failing?","commit_id":"378c307238933e76cce09b9bae9b7c058966f9e8"},{"author":{"_account_id":2,"name":"Monty Taylor","email":"mordred@inaugust.com","username":"mordred"},"change_message_id":"8d93858db3bd455e80ff76410054e04da9777ab3","unresolved":false,"context_lines":[{"line_number":69,"context_line":""},{"line_number":70,"context_line":"The goal of the assertion is to not break users, not merely to follow a set of"},{"line_number":71,"context_line":"instructions. Additionally, never-breaks-compat is intended to be a stricter"},{"line_number":72,"context_line":"superset of standard-deprecation-policy."}],"source_content_type":"text/x-rst","patch_set":2,"id":"1a1ced50_a99bcc16","line":72,"in_reply_to":"1a1ced50_94f10004","updated":"2017-03-22 16:48:15.000000000","message":"It should be possible to be both, or else I\u0027ve written it poorly. It should essentially be like standard-deprecation ... except that the deprecation period never ends and the deprecated thing is never actually removed. So a sequence of strictness, starting with \"we do whatever we feel like\" to \"we version our api\" to \"we follow deprecation policy\" to \"we never make backwards incompat changes\"","commit_id":"378c307238933e76cce09b9bae9b7c058966f9e8"},{"author":{"_account_id":1179,"name":"Clay Gerrard","email":"clay.gerrard@gmail.com","username":"clay-gerrard"},"change_message_id":"aab126ea86b343b530f70a05754766c000046ab4","unresolved":false,"context_lines":[{"line_number":4,"context_line":"  Unported License."},{"line_number":5,"context_line":"  http://creativecommons.org/licenses/by/3.0/legalcode"},{"line_number":6,"context_line":""},{"line_number":7,"context_line":".. _`tag-assert:never-breaks-compat`:"},{"line_number":8,"context_line":""},{"line_number":9,"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"},{"line_number":10,"context_line":"assert:never-breaks-compat"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1a1ced50_8c11b45f","line":7,"updated":"2017-03-22 21:06:39.000000000","message":"I hate this name.  \"never say never\"","commit_id":"8d915f0064a97778433c8d26a195a93b40034826"},{"author":{"_account_id":6482,"name":"Steve Martinelli","email":"s.martinelli@gmail.com","username":"stevemar"},"change_message_id":"a30ad3f723fee989771b017d4f14e240377635fd","unresolved":false,"context_lines":[{"line_number":4,"context_line":"  Unported License."},{"line_number":5,"context_line":"  http://creativecommons.org/licenses/by/3.0/legalcode"},{"line_number":6,"context_line":""},{"line_number":7,"context_line":".. _`tag-assert:never-breaks-compat`:"},{"line_number":8,"context_line":""},{"line_number":9,"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"},{"line_number":10,"context_line":"assert:never-breaks-compat"}],"source_content_type":"text/x-rst","patch_set":3,"id":"ffe62b97_197a4df0","line":7,"in_reply_to":"1a1ced50_8c11b45f","updated":"2017-03-27 16:56:26.000000000","message":"agreed on not liking \"never\"\n\n  assert:always-compatible\n  assert:fully-compatible\n  assert:hasnt-broken-compatability-yet :)","commit_id":"8d915f0064a97778433c8d26a195a93b40034826"},{"author":{"_account_id":3153,"name":"Emilien Macchi","email":"emilien@redhat.com","username":"emilienm"},"change_message_id":"a4a47577298838ced9775959408e9b0646a15c39","unresolved":false,"context_lines":[{"line_number":4,"context_line":"  Unported License."},{"line_number":5,"context_line":"  http://creativecommons.org/licenses/by/3.0/legalcode"},{"line_number":6,"context_line":""},{"line_number":7,"context_line":".. _`tag-assert:never-breaks-compat`:"},{"line_number":8,"context_line":""},{"line_number":9,"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"},{"line_number":10,"context_line":"assert:never-breaks-compat"}],"source_content_type":"text/x-rst","patch_set":3,"id":"ffe62b97_ee56885c","line":7,"in_reply_to":"ffe62b97_197a4df0","updated":"2017-03-28 15:34:37.000000000","message":"fully-compabible sounds better. +1","commit_id":"8d915f0064a97778433c8d26a195a93b40034826"},{"author":{"_account_id":10670,"name":"Michael McCune","email":"elmiko@redhat.com","username":"mimccune"},"change_message_id":"294d699da6449e6d251d50e5f7333749eefb5f9d","unresolved":false,"context_lines":[{"line_number":4,"context_line":"  Unported License."},{"line_number":5,"context_line":"  http://creativecommons.org/licenses/by/3.0/legalcode"},{"line_number":6,"context_line":""},{"line_number":7,"context_line":".. _`tag-assert:never-breaks-compat`:"},{"line_number":8,"context_line":""},{"line_number":9,"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"},{"line_number":10,"context_line":"assert:never-breaks-compat"}],"source_content_type":"text/x-rst","patch_set":3,"id":"bff0334d_20cb9b1e","line":7,"in_reply_to":"ffe62b97_ee56885c","updated":"2017-04-07 17:47:07.000000000","message":"+1 to fully-compatible\n\nalthough, i do appreciate option 3 XD","commit_id":"8d915f0064a97778433c8d26a195a93b40034826"},{"author":{"_account_id":15343,"name":"Tim Burke","email":"tburke@nvidia.com","username":"tburke"},"change_message_id":"5827d62e90ea9f77f066bf52d3048adb3f1f751b","unresolved":false,"context_lines":[{"line_number":90,"context_line":"assert that they will never break backwards compatibility. More specifically,"},{"line_number":91,"context_line":"that means:"},{"line_number":92,"context_line":""},{"line_number":93,"context_line":"#. Features, APIs or configuration options, once released, will continue to"},{"line_number":94,"context_line":"   work in perpetuity."},{"line_number":95,"context_line":""},{"line_number":96,"context_line":"#. Features, APIs or configuration options may be marked as deprecated."}],"source_content_type":"text/x-rst","patch_set":3,"id":"1a1ced50_0adbe41b","line":93,"range":{"start_line":93,"start_character":13,"end_line":93,"end_character":42},"updated":"2017-04-11 02:18:21.000000000","message":"These seem orthogonal; perhaps there should be two tags?\n\nFWIW, swift (as I suppose the canonical example of a project with longer-than-standard-policy deprecation cycles and a firm commitment to maintaining client APIs) still intends to remove config options [1] and has done so in the past [2].\n\n[1] https://review.openstack.org/#/c/417209/ and http://eavesdrop.openstack.org/irclogs/%23openstack-swift/%23openstack-swift.2017-01-05.log.html#t2017-01-05T21:41:15\n\n[2] https://review.openstack.org/#/c/63326/ removed the max_large_object_get_time proxy-server option in favor of a middleware config option, max_get_time.","commit_id":"8d915f0064a97778433c8d26a195a93b40034826"},{"author":{"_account_id":15343,"name":"Tim Burke","email":"tburke@nvidia.com","username":"tburke"},"change_message_id":"5827d62e90ea9f77f066bf52d3048adb3f1f751b","unresolved":false,"context_lines":[{"line_number":91,"context_line":"that means:"},{"line_number":92,"context_line":""},{"line_number":93,"context_line":"#. Features, APIs or configuration options, once released, will continue to"},{"line_number":94,"context_line":"   work in perpetuity."},{"line_number":95,"context_line":""},{"line_number":96,"context_line":"#. Features, APIs or configuration options may be marked as deprecated."},{"line_number":97,"context_line":"   Although this does not mean that they will be removed at some point in the"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1a1ced50_e51ebb0a","line":94,"range":{"start_line":94,"start_character":3,"end_line":94,"end_character":7},"updated":"2017-04-11 02:18:21.000000000","message":"Do we ever define what it means for it to have \"worked\"? Clearly, if the service only ever responded 500 or something, it was broken -- but what about less-obvious cases?\n\nMaybe this is intentionally vague -- we trust that the teams responsible for the APIs and configs are deeply involved with their users (both API clients and deployers/operators), and so we defer to their judgment for determining whether a behavior is\n\n* working as intended,\n* broken, or\n* a known wart with users working around it or otherwise building solutions on top of it.\n\nThe tag is then saying that this team is committed\n\n* to erring on the side of known-wart over broken for a given behavior, and\n* in the known-wart case, to preserving the wart indefinitely.\n\nThis interpretation would then resolve Clay\u0027s concern about API-breaking security fixes -- security hole \u003d\u003d broken, whether things had been built relying on that behavior or not. (Although I think that case may still be worth explicitly calling out.)","commit_id":"8d915f0064a97778433c8d26a195a93b40034826"},{"author":{"_account_id":1179,"name":"Clay Gerrard","email":"clay.gerrard@gmail.com","username":"clay-gerrard"},"change_message_id":"aab126ea86b343b530f70a05754766c000046ab4","unresolved":false,"context_lines":[{"line_number":105,"context_line":"   problem."},{"line_number":106,"context_line":""},{"line_number":107,"context_line":"#. If a breaking change is accidentally released, the project will immediately"},{"line_number":108,"context_line":"   make a release reverting the behavior change. The project will also then"},{"line_number":109,"context_line":"   add testing to cover the hole that allowed the API breakage to slip through."},{"line_number":110,"context_line":"   A judgement call will have to be made if the breaking change slipped through"},{"line_number":111,"context_line":"   and was not noticed for long enough that fixing the API break would break"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1a1ced50_ec0a2825","line":108,"updated":"2017-03-22 21:06:39.000000000","message":"see!\n\nthere should be a thing here for security too - like \"when faced with a mistake and given the choice that either the behavior of the api changes to include a new restriction or it\u0027s impossible to use safely prefer to fix it\"","commit_id":"8d915f0064a97778433c8d26a195a93b40034826"},{"author":{"_account_id":10670,"name":"Michael McCune","email":"elmiko@redhat.com","username":"mimccune"},"change_message_id":"294d699da6449e6d251d50e5f7333749eefb5f9d","unresolved":false,"context_lines":[{"line_number":105,"context_line":"   problem."},{"line_number":106,"context_line":""},{"line_number":107,"context_line":"#. If a breaking change is accidentally released, the project will immediately"},{"line_number":108,"context_line":"   make a release reverting the behavior change. The project will also then"},{"line_number":109,"context_line":"   add testing to cover the hole that allowed the API breakage to slip through."},{"line_number":110,"context_line":"   A judgement call will have to be made if the breaking change slipped through"},{"line_number":111,"context_line":"   and was not noticed for long enough that fixing the API break would break"}],"source_content_type":"text/x-rst","patch_set":3,"id":"bff0334d_6055231d","line":108,"in_reply_to":"1a1ced50_ec0a2825","updated":"2017-04-07 17:47:07.000000000","message":"+1","commit_id":"8d915f0064a97778433c8d26a195a93b40034826"}]}