)]}'
{"specs/juno/pbr-semver.rst":[{"author":{"_account_id":4190,"name":"lifeless","email":"robertc@robertcollins.net","username":"lifeless"},"change_message_id":"462744d6bc9bf19c1d8fa2a2a3a2b3706216796e","unresolved":false,"context_lines":[{"line_number":9,"context_line":"OpenStack uses semver but pbr doesn\u0027t actually understand it today."},{"line_number":10,"context_line":"Teaching it to understand semver will allow less thought and more automation"},{"line_number":11,"context_line":"by developers, as well as better and clearer version numbers for folk doing"},{"line_number":12,"context_line":"continual deployment of OpenStack."},{"line_number":13,"context_line":""},{"line_number":14,"context_line":"Problem description"},{"line_number":15,"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_0ed157cd","line":12,"updated":"2014-06-09 06:32:14.000000000","message":"Done.","commit_id":"a4e585d8262df0ca5b80b98801a2aec50731d429"},{"author":{"_account_id":5638,"name":"Davanum Srinivas","email":"davanum@gmail.com","username":"dims-v"},"change_message_id":"ae3041b1436c5937249efbed8906b4b4af77e31d","unresolved":false,"context_lines":[{"line_number":9,"context_line":"OpenStack uses semver but pbr doesn\u0027t actually understand it today."},{"line_number":10,"context_line":"Teaching it to understand semver will allow less thought and more automation"},{"line_number":11,"context_line":"by developers, as well as better and clearer version numbers for folk doing"},{"line_number":12,"context_line":"continual deployment of OpenStack."},{"line_number":13,"context_line":""},{"line_number":14,"context_line":"Problem description"},{"line_number":15,"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_8f8825e9","line":12,"updated":"2014-05-29 23:10:11.000000000","message":"add (CD) as we use CD below.","commit_id":"a4e585d8262df0ca5b80b98801a2aec50731d429"},{"author":{"_account_id":4190,"name":"lifeless","email":"robertc@robertcollins.net","username":"lifeless"},"change_message_id":"462744d6bc9bf19c1d8fa2a2a3a2b3706216796e","unresolved":false,"context_lines":[{"line_number":18,"context_line":"versions of 1.3.2.N.g$sha. pip currently considers such versions invalid, but if"},{"line_number":19,"context_line":"pip learns about build tags - the g$sha, then the version would be considered a"},{"line_number":20,"context_line":"release, but often the intent of an untagged commit is to be a developer"},{"line_number":21,"context_line":"version for local installs / testing. So this is not PEP-440 compliant."},{"line_number":22,"context_line":"Conflicting with this is the desire of CD deployers and CD packagers to have"},{"line_number":23,"context_line":"monotonic versions that can be used to install packages on e.g. Debian systems,"},{"line_number":24,"context_line":"but subsequent tags can collide with these versions as well."}],"source_content_type":"text/x-rst","patch_set":1,"id":"1ae5cdf2_2ed613c6","line":21,"updated":"2014-06-09 06:32:14.000000000","message":"Done.","commit_id":"a4e585d8262df0ca5b80b98801a2aec50731d429"},{"author":{"_account_id":5638,"name":"Davanum Srinivas","email":"davanum@gmail.com","username":"dims-v"},"change_message_id":"ae3041b1436c5937249efbed8906b4b4af77e31d","unresolved":false,"context_lines":[{"line_number":18,"context_line":"versions of 1.3.2.N.g$sha. pip currently considers such versions invalid, but if"},{"line_number":19,"context_line":"pip learns about build tags - the g$sha, then the version would be considered a"},{"line_number":20,"context_line":"release, but often the intent of an untagged commit is to be a developer"},{"line_number":21,"context_line":"version for local installs / testing. So this is not PEP-440 compliant."},{"line_number":22,"context_line":"Conflicting with this is the desire of CD deployers and CD packagers to have"},{"line_number":23,"context_line":"monotonic versions that can be used to install packages on e.g. Debian systems,"},{"line_number":24,"context_line":"but subsequent tags can collide with these versions as well."}],"source_content_type":"text/x-rst","patch_set":1,"id":"1ae5cdf2_8f3ae534","line":21,"updated":"2014-05-29 23:10:11.000000000","message":"Pointer to PEP-440 would be useful for some folks - http://legacy.python.org/dev/peps/pep-0440/","commit_id":"a4e585d8262df0ca5b80b98801a2aec50731d429"},{"author":{"_account_id":4190,"name":"lifeless","email":"robertc@robertcollins.net","username":"lifeless"},"change_message_id":"462744d6bc9bf19c1d8fa2a2a3a2b3706216796e","unresolved":false,"context_lines":[{"line_number":56,"context_line":"  had been made when a backwards incompatible change was made, or when a"},{"line_number":57,"context_line":"  deprecation is made, or major new functionality. This allows us to calculate"},{"line_number":58,"context_line":"  the next semver version number automatically (and patches in gerrit can"},{"line_number":59,"context_line":"  update this as development progresses). "},{"line_number":60,"context_line":""},{"line_number":61,"context_line":"* For untagged postversioned builds, generate devN versions - e.g."},{"line_number":62,"context_line":"  x.y.z.dev4.gHASH, where x.y.z are derived by applying the semver rules with"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1ae5cdf2_4eda7fea","line":59,"updated":"2014-06-09 06:32:14.000000000","message":"Done.","commit_id":"a4e585d8262df0ca5b80b98801a2aec50731d429"},{"author":{"_account_id":5638,"name":"Davanum Srinivas","email":"davanum@gmail.com","username":"dims-v"},"change_message_id":"ae3041b1436c5937249efbed8906b4b4af77e31d","unresolved":false,"context_lines":[{"line_number":56,"context_line":"  had been made when a backwards incompatible change was made, or when a"},{"line_number":57,"context_line":"  deprecation is made, or major new functionality. This allows us to calculate"},{"line_number":58,"context_line":"  the next semver version number automatically (and patches in gerrit can"},{"line_number":59,"context_line":"  update this as development progresses). "},{"line_number":60,"context_line":""},{"line_number":61,"context_line":"* For untagged postversioned builds, generate devN versions - e.g."},{"line_number":62,"context_line":"  x.y.z.dev4.gHASH, where x.y.z are derived by applying the semver rules with"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1ae5cdf2_cf506d61","line":59,"updated":"2014-05-29 23:10:11.000000000","message":"extra space","commit_id":"a4e585d8262df0ca5b80b98801a2aec50731d429"},{"author":{"_account_id":4190,"name":"lifeless","email":"robertc@robertcollins.net","username":"lifeless"},"change_message_id":"462744d6bc9bf19c1d8fa2a2a3a2b3706216796e","unresolved":false,"context_lines":[{"line_number":67,"context_line":"  (e.g. if there is a newer tag than the version being tagged in the history of"},{"line_number":68,"context_line":"  the branch, thats an error). Alpha, beta and rc tagging can be automated too."},{"line_number":69,"context_line":""},{"line_number":70,"context_line":"* Provide a python API for getting version_info style version data."},{"line_number":71,"context_line":""},{"line_number":72,"context_line":"* Provider a new command to output Debian package version compatible version"},{"line_number":73,"context_line":"  strings.  This primarily involves translating PEP-440 precedence rules into"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1ae5cdf2_6ed73bc0","line":70,"updated":"2014-06-09 06:32:14.000000000","message":"Added.","commit_id":"a4e585d8262df0ca5b80b98801a2aec50731d429"},{"author":{"_account_id":5638,"name":"Davanum Srinivas","email":"davanum@gmail.com","username":"dims-v"},"change_message_id":"ae3041b1436c5937249efbed8906b4b4af77e31d","unresolved":false,"context_lines":[{"line_number":67,"context_line":"  (e.g. if there is a newer tag than the version being tagged in the history of"},{"line_number":68,"context_line":"  the branch, thats an error). Alpha, beta and rc tagging can be automated too."},{"line_number":69,"context_line":""},{"line_number":70,"context_line":"* Provide a python API for getting version_info style version data."},{"line_number":71,"context_line":""},{"line_number":72,"context_line":"* Provider a new command to output Debian package version compatible version"},{"line_number":73,"context_line":"  strings.  This primarily involves translating PEP-440 precedence rules into"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1ae5cdf2_af01613b","line":70,"updated":"2014-05-29 23:10:11.000000000","message":"Any method signatures (for the API) we can think of? or is it too early?","commit_id":"a4e585d8262df0ca5b80b98801a2aec50731d429"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"89f7ed39592d18ebc3fcc6b4012c3e9bd6c9ea51","unresolved":false,"context_lines":[{"line_number":69,"context_line":""},{"line_number":70,"context_line":"* Provide a python API for getting version_info style version data."},{"line_number":71,"context_line":""},{"line_number":72,"context_line":"* Provider a new command to output Debian package version compatible version"},{"line_number":73,"context_line":"  strings.  This primarily involves translating PEP-440 precedence rules into"},{"line_number":74,"context_line":"  Debian ~ and . component separators."},{"line_number":75,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"1ae5cdf2_10fb7147","line":72,"updated":"2014-06-05 21:25:04.000000000","message":"Can we avoid including in this spec a debian package version solution and maybe do this in later commits. I for one would like rpm version compatible versions and I think this spec has enough in it to just fix 1 problem and not 2.","commit_id":"a4e585d8262df0ca5b80b98801a2aec50731d429"},{"author":{"_account_id":4190,"name":"lifeless","email":"robertc@robertcollins.net","username":"lifeless"},"change_message_id":"462744d6bc9bf19c1d8fa2a2a3a2b3706216796e","unresolved":false,"context_lines":[{"line_number":69,"context_line":""},{"line_number":70,"context_line":"* Provide a python API for getting version_info style version data."},{"line_number":71,"context_line":""},{"line_number":72,"context_line":"* Provider a new command to output Debian package version compatible version"},{"line_number":73,"context_line":"  strings.  This primarily involves translating PEP-440 precedence rules into"},{"line_number":74,"context_line":"  Debian ~ and . component separators."},{"line_number":75,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"1ae5cdf2_8ee487ad","line":72,"updated":"2014-06-09 06:32:14.000000000","message":"I think in terms of assessing semver, we need to do it here - there will naturally be many commits to make this happen in code. I\u0027d hate to have a design that doesn\u0027t work because we didn\u0027t consider RPM. How does one represent \u0027sorts before\u0027 in RPM version strings? How are alpha/beta markers handled? OTOH if you\u0027re totally confident we can represent everything in this spec in RPM format, thats fine - I\u0027m happy to add that later. For Debian though, mapping semver to Debian *is* different to the default way of doing things, so I do want it reviewed before we commit to semver being doable.","commit_id":"a4e585d8262df0ca5b80b98801a2aec50731d429"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"89f7ed39592d18ebc3fcc6b4012c3e9bd6c9ea51","unresolved":false,"context_lines":[{"line_number":74,"context_line":"  Debian ~ and . component separators."},{"line_number":75,"context_line":""},{"line_number":76,"context_line":"* sdist and the new debian version string command will accept a --no-rc"},{"line_number":77,"context_line":"  parameter which will tell them to only ever emit versions that are a) normal"},{"line_number":78,"context_line":"  releases or b) devN builds. This resolves the sorting ambiguity in semver"},{"line_number":79,"context_line":"  where devN is lower than *any* pre-release build, but version numbers may"},{"line_number":80,"context_line":"  not have both a pre-release version *and* a devN version component. CD"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1ae5cdf2_706915f8","line":77,"updated":"2014-06-05 21:25:04.000000000","message":"Same as above, would rather just solve 1 problem, not bring in debian version strings in this spec. Do 1 thing well ;)","commit_id":"a4e585d8262df0ca5b80b98801a2aec50731d429"},{"author":{"_account_id":4190,"name":"lifeless","email":"robertc@robertcollins.net","username":"lifeless"},"change_message_id":"462744d6bc9bf19c1d8fa2a2a3a2b3706216796e","unresolved":false,"context_lines":[{"line_number":74,"context_line":"  Debian ~ and . component separators."},{"line_number":75,"context_line":""},{"line_number":76,"context_line":"* sdist and the new debian version string command will accept a --no-rc"},{"line_number":77,"context_line":"  parameter which will tell them to only ever emit versions that are a) normal"},{"line_number":78,"context_line":"  releases or b) devN builds. This resolves the sorting ambiguity in semver"},{"line_number":79,"context_line":"  where devN is lower than *any* pre-release build, but version numbers may"},{"line_number":80,"context_line":"  not have both a pre-release version *and* a devN version component. CD"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1ae5cdf2_aee1439c","line":77,"updated":"2014-06-09 06:32:14.000000000","message":"The 1 thing we want to do well is either compatible, or incompatible with this other thing that we also need to do. Since the point of /specs/ is to get the design input - well, I can split it up if you will be able to review it more effectively that way, but since the algorithm below *cannot be expressed correctly* without considering the impact on Debian\u0027s semantics, I\u0027d like a very strong reason to separate these tightly coupled problems.","commit_id":"a4e585d8262df0ca5b80b98801a2aec50731d429"},{"author":{"_account_id":4190,"name":"lifeless","email":"robertc@robertcollins.net","username":"lifeless"},"change_message_id":"462744d6bc9bf19c1d8fa2a2a3a2b3706216796e","unresolved":false,"context_lines":[{"line_number":81,"context_line":"  deployers can then include --no-rc in their scripts and have a consistent"},{"line_number":82,"context_line":"  timeline (as long as they\u0027re pulling from a monotonically advancing branch)"},{"line_number":83,"context_line":"  while regular users and packagers will want to select regular builds only."},{"line_number":84,"context_line":"  There is one caveat here which is that new point releases of old versions"},{"line_number":85,"context_line":"  must not be merged into the history of trunk, or the devN versions will be"},{"line_number":86,"context_line":"  reset at that point."},{"line_number":87,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"1ae5cdf2_ceedaf90","line":84,"updated":"2014-06-09 06:32:14.000000000","message":"Done.","commit_id":"a4e585d8262df0ca5b80b98801a2aec50731d429"},{"author":{"_account_id":5638,"name":"Davanum Srinivas","email":"davanum@gmail.com","username":"dims-v"},"change_message_id":"ae3041b1436c5937249efbed8906b4b4af77e31d","unresolved":false,"context_lines":[{"line_number":81,"context_line":"  deployers can then include --no-rc in their scripts and have a consistent"},{"line_number":82,"context_line":"  timeline (as long as they\u0027re pulling from a monotonically advancing branch)"},{"line_number":83,"context_line":"  while regular users and packagers will want to select regular builds only."},{"line_number":84,"context_line":"  There is one caveat here which is that new point releases of old versions"},{"line_number":85,"context_line":"  must not be merged into the history of trunk, or the devN versions will be"},{"line_number":86,"context_line":"  reset at that point."},{"line_number":87,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"1ae5cdf2_ef80c98d","line":84,"updated":"2014-05-29 23:10:11.000000000","message":"Highlight this a bit more (new paragraph?)","commit_id":"a4e585d8262df0ca5b80b98801a2aec50731d429"},{"author":{"_account_id":5638,"name":"Davanum Srinivas","email":"davanum@gmail.com","username":"dims-v"},"change_message_id":"ae3041b1436c5937249efbed8906b4b4af77e31d","unresolved":false,"context_lines":[{"line_number":89,"context_line":"^^^^^^^^^^^^^^^^^"},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"There are four incrementable components in a version: major, minor, patch and"},{"line_number":92,"context_line":"pre-release. The following is a description of how pbr will implement the "},{"line_number":93,"context_line":"assignment rules described by semver.rst."},{"line_number":94,"context_line":""},{"line_number":95,"context_line":"1. If there are one or more tags for a commit then the highest such tag is"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1ae5cdf2_0f7ed5ae","line":92,"updated":"2014-05-29 23:10:11.000000000","message":"extra space","commit_id":"a4e585d8262df0ca5b80b98801a2aec50731d429"},{"author":{"_account_id":5638,"name":"Davanum Srinivas","email":"davanum@gmail.com","username":"dims-v"},"change_message_id":"ae3041b1436c5937249efbed8906b4b4af77e31d","unresolved":false,"context_lines":[{"line_number":98,"context_line":"1. If the last tag is a pre-release tag, then the --no-rc option is consulted."},{"line_number":99,"context_line":"   If set, pre-release tags are not considered when looking for for the last"},{"line_number":100,"context_line":"   tag."},{"line_number":101,"context_line":"   "},{"line_number":102,"context_line":"1. The highest eligible tag reachable from the commit is considered to be the"},{"line_number":103,"context_line":"   \u0027last tag\u0027. If there is more than one tag with equal distance (e.g. an rc"},{"line_number":104,"context_line":"   and a final tag on a single commit) then the highest tag is still used. If"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1ae5cdf2_6f44b974","line":101,"updated":"2014-05-29 23:10:11.000000000","message":"extra space","commit_id":"a4e585d8262df0ca5b80b98801a2aec50731d429"},{"author":{"_account_id":5638,"name":"Davanum Srinivas","email":"davanum@gmail.com","username":"dims-v"},"change_message_id":"ae3041b1436c5937249efbed8906b4b4af77e31d","unresolved":false,"context_lines":[{"line_number":109,"context_line":"1. If the distance to the last tag is non-zero at minimum a patch level"},{"line_number":110,"context_line":"   increment is required and the version shall be a devN version."},{"line_number":111,"context_line":""},{"line_number":112,"context_line":"1. If the option ``pbr_deprecation`` is set in setup.cfg to the same"},{"line_number":113,"context_line":"   major and minor components (e.g. last tag is 1.2.3 and pbr_deprecation is"},{"line_number":114,"context_line":"   1.2.1, or just 1.2) then a minor increment is required."},{"line_number":115,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"1ae5cdf2_8a2573ad","line":112,"updated":"2014-05-29 23:10:11.000000000","message":"Can we please add some example setup.cfg entries?","commit_id":"a4e585d8262df0ca5b80b98801a2aec50731d429"},{"author":{"_account_id":4190,"name":"lifeless","email":"robertc@robertcollins.net","username":"lifeless"},"change_message_id":"462744d6bc9bf19c1d8fa2a2a3a2b3706216796e","unresolved":false,"context_lines":[{"line_number":161,"context_line":"We could do nothing, but right now folk are reinventing stuff in adhoc fashions"},{"line_number":162,"context_line":"and there is no ability to reuse their solutions in a systematic fashion."},{"line_number":163,"context_line":""},{"line_number":164,"context_line":"Impact on Existing APIs"},{"line_number":165,"context_line":"-----------------------"},{"line_number":166,"context_line":""},{"line_number":167,"context_line":"No public APIs change (since pbr has approximately no public APIs at all)."}],"source_content_type":"text/x-rst","patch_set":1,"id":"1ae5cdf2_eef26b6e","line":164,"updated":"2014-06-09 06:32:14.000000000","message":"Good suggestion. We did that a few months back. How about we do it again when the code to permit this is ready to land.","commit_id":"a4e585d8262df0ca5b80b98801a2aec50731d429"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"89f7ed39592d18ebc3fcc6b4012c3e9bd6c9ea51","unresolved":false,"context_lines":[{"line_number":161,"context_line":"We could do nothing, but right now folk are reinventing stuff in adhoc fashions"},{"line_number":162,"context_line":"and there is no ability to reuse their solutions in a systematic fashion."},{"line_number":163,"context_line":""},{"line_number":164,"context_line":"Impact on Existing APIs"},{"line_number":165,"context_line":"-----------------------"},{"line_number":166,"context_line":""},{"line_number":167,"context_line":"No public APIs change (since pbr has approximately no public APIs at all)."}],"source_content_type":"text/x-rst","patch_set":1,"id":"1ae5cdf2_d3159340","line":164,"updated":"2014-06-05 21:25:04.000000000","message":"We might want to warn people on the ML that the version scheme is changing (again), this lets people know that any software they\u0027ve built to handle the pbr versions will need changes.","commit_id":"a4e585d8262df0ca5b80b98801a2aec50731d429"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"187d137bc3f1defbbe3cc53ff227c84b8a7974e8","unresolved":false,"context_lines":[{"line_number":53,"context_line":"----------------"},{"line_number":54,"context_line":""},{"line_number":55,"context_line":"* Change from emitting 1.2.3a4 (which some projects are using) to 1.2.3.0a4,"},{"line_number":56,"context_line":"  updating the semver docs accordingly. This gets us PEP440 compatibility."},{"line_number":57,"context_line":""},{"line_number":58,"context_line":"* Add metadata fields to setup.cfg to allow recording the last release that"},{"line_number":59,"context_line":"  had been made when a backwards incompatible change was made, or when a"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1ae5cdf2_2552a413","line":56,"updated":"2014-06-09 14:40:59.000000000","message":"Is this a change to pbr, or to the way we create those alpha release tags in git?","commit_id":"19466ac84a880d70b5ed4a6588eb93bd01ebab23"},{"author":{"_account_id":4190,"name":"lifeless","email":"robertc@robertcollins.net","username":"lifeless"},"change_message_id":"78b91578bfd8c1a926f3e49437094b67156c04d5","unresolved":false,"context_lines":[{"line_number":53,"context_line":"----------------"},{"line_number":54,"context_line":""},{"line_number":55,"context_line":"* Change from emitting 1.2.3a4 (which some projects are using) to 1.2.3.0a4,"},{"line_number":56,"context_line":"  updating the semver docs accordingly. This gets us PEP440 compatibility."},{"line_number":57,"context_line":""},{"line_number":58,"context_line":"* Add metadata fields to setup.cfg to allow recording the last release that"},{"line_number":59,"context_line":"  had been made when a backwards incompatible change was made, or when a"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1ae5cdf2_392abf90","line":56,"updated":"2014-06-09 20:24:49.000000000","message":"Tags are currently made by hand (though I\u0027d like to eventually automate that, which this spec should enable. For now though, it will be a change in the format of the tags we ask people to create. Note too that for backwards compat we can parse the old form as the new form. I don\u0027t know if I put that in the spec, but the patch set for it is already up :).","commit_id":"19466ac84a880d70b5ed4a6588eb93bd01ebab23"},{"author":{"_account_id":8041,"name":"Petr Blaho","email":"pblaho@redhat.com","username":"pblaho"},"change_message_id":"ce924009dc2b7efeaeb976f6405f4011db91a8e5","unresolved":false,"context_lines":[{"line_number":77,"context_line":"      version_info \u003d pbr.version.Version(\u0027MYPACKAGENAME\u0027).version_info()"},{"line_number":78,"context_line":""},{"line_number":79,"context_line":""},{"line_number":80,"context_line":"* Provider a new command to output Debian package version compatible version"},{"line_number":81,"context_line":"  strings.  This primarily involves translating PEP-440 precedence rules into"},{"line_number":82,"context_line":"  Debian ~ and . component separators."},{"line_number":83,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"1ae5cdf2_7111d2ab","line":80,"updated":"2014-06-09 12:43:46.000000000","message":"Typo Provider -\u003e Provide","commit_id":"19466ac84a880d70b5ed4a6588eb93bd01ebab23"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"187d137bc3f1defbbe3cc53ff227c84b8a7974e8","unresolved":false,"context_lines":[{"line_number":81,"context_line":"  strings.  This primarily involves translating PEP-440 precedence rules into"},{"line_number":82,"context_line":"  Debian ~ and . component separators."},{"line_number":83,"context_line":""},{"line_number":84,"context_line":"* sdist and the new debian version string command will accept a --no-rc"},{"line_number":85,"context_line":"  parameter which will tell them to only ever emit versions that are a) normal"},{"line_number":86,"context_line":"  releases or b) devN builds. This resolves the sorting ambiguity in semver"},{"line_number":87,"context_line":"  where devN is lower than *any* pre-release build, but version numbers may"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1ae5cdf2_256384b2","line":84,"updated":"2014-06-09 14:40:59.000000000","message":"Does the --version option/command need to honor this flag, too?","commit_id":"19466ac84a880d70b5ed4a6588eb93bd01ebab23"},{"author":{"_account_id":4190,"name":"lifeless","email":"robertc@robertcollins.net","username":"lifeless"},"change_message_id":"78b91578bfd8c1a926f3e49437094b67156c04d5","unresolved":false,"context_lines":[{"line_number":81,"context_line":"  strings.  This primarily involves translating PEP-440 precedence rules into"},{"line_number":82,"context_line":"  Debian ~ and . component separators."},{"line_number":83,"context_line":""},{"line_number":84,"context_line":"* sdist and the new debian version string command will accept a --no-rc"},{"line_number":85,"context_line":"  parameter which will tell them to only ever emit versions that are a) normal"},{"line_number":86,"context_line":"  releases or b) devN builds. This resolves the sorting ambiguity in semver"},{"line_number":87,"context_line":"  where devN is lower than *any* pre-release build, but version numbers may"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1ae5cdf2_59186b84","line":84,"updated":"2014-06-09 20:24:49.000000000","message":"The version value in setup.cfg forces a particular version and prevents all automatic version calculation, so no. Thats part of the existing contract, but I can call it out if you want. (This is \u0027change proposed\u0027 so I tried to not redocument *everything* :)).","commit_id":"19466ac84a880d70b5ed4a6588eb93bd01ebab23"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"10714b999c314e1efda0a5724b267d6ce053ea90","unresolved":false,"context_lines":[{"line_number":81,"context_line":"  strings.  This primarily involves translating PEP-440 precedence rules into"},{"line_number":82,"context_line":"  Debian ~ and . component separators."},{"line_number":83,"context_line":""},{"line_number":84,"context_line":"* sdist and the new debian version string command will accept a --no-rc"},{"line_number":85,"context_line":"  parameter which will tell them to only ever emit versions that are a) normal"},{"line_number":86,"context_line":"  releases or b) devN builds. This resolves the sorting ambiguity in semver"},{"line_number":87,"context_line":"  where devN is lower than *any* pre-release build, but version numbers may"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1ae5cdf2_983e52d9","line":84,"in_reply_to":"1ae5cdf2_59186b84","updated":"2014-06-10 12:38:12.000000000","message":"Sorry, I meant when I run \"python setup.py --version\" to discover the version of a package, should I be able to also include \"--no-rc\" to change the output in the way you describe.","commit_id":"19466ac84a880d70b5ed4a6588eb93bd01ebab23"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"187d137bc3f1defbbe3cc53ff227c84b8a7974e8","unresolved":false,"context_lines":[{"line_number":88,"context_line":"  not have both a pre-release version *and* a devN version component. CD"},{"line_number":89,"context_line":"  deployers can then include --no-rc in their scripts and have a consistent"},{"line_number":90,"context_line":"  timeline (as long as they\u0027re pulling from a monotonically advancing branch)"},{"line_number":91,"context_line":"  while regular users and packagers will want to select regular builds only."},{"line_number":92,"context_line":""},{"line_number":93,"context_line":"  There is one caveat here which is that new point releases of old versions"},{"line_number":94,"context_line":"  must not be merged into the history of trunk, or the devN versions will be"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1ae5cdf2_a547941c","line":91,"updated":"2014-06-09 14:40:59.000000000","message":"By \"normal release\" and \"reguilar builds\" do you mean \"not an alpha or beta release\"? We\u0027re planning to tag more alpha releases, so I want to make sure I understand how this flag might change the behavior of development versions that come after alpha versions in the git history.","commit_id":"19466ac84a880d70b5ed4a6588eb93bd01ebab23"},{"author":{"_account_id":4190,"name":"lifeless","email":"robertc@robertcollins.net","username":"lifeless"},"change_message_id":"78b91578bfd8c1a926f3e49437094b67156c04d5","unresolved":false,"context_lines":[{"line_number":88,"context_line":"  not have both a pre-release version *and* a devN version component. CD"},{"line_number":89,"context_line":"  deployers can then include --no-rc in their scripts and have a consistent"},{"line_number":90,"context_line":"  timeline (as long as they\u0027re pulling from a monotonically advancing branch)"},{"line_number":91,"context_line":"  while regular users and packagers will want to select regular builds only."},{"line_number":92,"context_line":""},{"line_number":93,"context_line":"  There is one caveat here which is that new point releases of old versions"},{"line_number":94,"context_line":"  must not be merged into the history of trunk, or the devN versions will be"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1ae5cdf2_791b6780","line":91,"updated":"2014-06-09 20:24:49.000000000","message":"Normal version is defined in semver.rst in the pbr repository. Its specifically X.Y.Z only. Tagging alpha and beta will cause releases with the alpha and beta version, which is fine. Alpha/Beta/Normal have a defined timeline. Any untagged build does not outside of \u0027before the version its a dev build of\u0027 , but CD folk want untagged builds to have timelines. So what they can do with this spec is use the N in devN to get a timeline as long as a) always use a branch with stable history, which b) never adds a tag between the last release and their planned new version (because that would wind back the clock[documented below]) and c) they never compare it to alpha or beta or rc versions because they have no defined relation in semver, nor an inferrable relation from the version string. So what --no-rc does is allows those CD folk to grab a devN build for the alpha, so they can compare it well.","commit_id":"19466ac84a880d70b5ed4a6588eb93bd01ebab23"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"187d137bc3f1defbbe3cc53ff227c84b8a7974e8","unresolved":false,"context_lines":[{"line_number":92,"context_line":""},{"line_number":93,"context_line":"  There is one caveat here which is that new point releases of old versions"},{"line_number":94,"context_line":"  must not be merged into the history of trunk, or the devN versions will be"},{"line_number":95,"context_line":"  reset at that point."},{"line_number":96,"context_line":""},{"line_number":97,"context_line":"New version rules"},{"line_number":98,"context_line":"^^^^^^^^^^^^^^^^^"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1ae5cdf2_05ba08e1","line":95,"updated":"2014-06-09 14:40:59.000000000","message":"How can we enforce this automatically? Do we need to? I think we\u0027re probably safe because we should always be working from master and then backporting changes, and releasing point releases from stable branches without merging back into master.","commit_id":"19466ac84a880d70b5ed4a6588eb93bd01ebab23"},{"author":{"_account_id":4190,"name":"lifeless","email":"robertc@robertcollins.net","username":"lifeless"},"change_message_id":"78b91578bfd8c1a926f3e49437094b67156c04d5","unresolved":false,"context_lines":[{"line_number":92,"context_line":""},{"line_number":93,"context_line":"  There is one caveat here which is that new point releases of old versions"},{"line_number":94,"context_line":"  must not be merged into the history of trunk, or the devN versions will be"},{"line_number":95,"context_line":"  reset at that point."},{"line_number":96,"context_line":""},{"line_number":97,"context_line":"New version rules"},{"line_number":98,"context_line":"^^^^^^^^^^^^^^^^^"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1ae5cdf2_9912f360","line":95,"updated":"2014-06-09 20:24:49.000000000","message":"I\u0027m not sure. But its documented now :)","commit_id":"19466ac84a880d70b5ed4a6588eb93bd01ebab23"},{"author":{"_account_id":4190,"name":"lifeless","email":"robertc@robertcollins.net","username":"lifeless"},"change_message_id":"78b91578bfd8c1a926f3e49437094b67156c04d5","unresolved":false,"context_lines":[{"line_number":121,"context_line":""},{"line_number":122,"context_line":"1. If the option ``pbr_deprecation`` is set in setup.cfg to the same"},{"line_number":123,"context_line":"   major and minor components (e.g. last tag is 1.2.3 and pbr_deprecation is"},{"line_number":124,"context_line":"   1.2.1, or just 1.2) then a minor increment is required."},{"line_number":125,"context_line":""},{"line_number":126,"context_line":"1. If the option ``pbr_major_feature`` is set in setup.cfg to the same"},{"line_number":127,"context_line":"   major and minor components (e.g. last tag is 1.2.3 and pbr_major_feature is"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1ae5cdf2_b915ef4a","line":124,"updated":"2014-06-09 20:24:49.000000000","message":"It means that the code in the tree has deprecated *something* in that version. I\u0027ll add a concordance of options at the top of this section for reference/clarity.","commit_id":"19466ac84a880d70b5ed4a6588eb93bd01ebab23"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"187d137bc3f1defbbe3cc53ff227c84b8a7974e8","unresolved":false,"context_lines":[{"line_number":121,"context_line":""},{"line_number":122,"context_line":"1. If the option ``pbr_deprecation`` is set in setup.cfg to the same"},{"line_number":123,"context_line":"   major and minor components (e.g. last tag is 1.2.3 and pbr_deprecation is"},{"line_number":124,"context_line":"   1.2.1, or just 1.2) then a minor increment is required."},{"line_number":125,"context_line":""},{"line_number":126,"context_line":"1. If the option ``pbr_major_feature`` is set in setup.cfg to the same"},{"line_number":127,"context_line":"   major and minor components (e.g. last tag is 1.2.3 and pbr_major_feature is"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1ae5cdf2_258d4432","line":124,"updated":"2014-06-09 14:40:59.000000000","message":"What does \"deprecation\" mean in this context?","commit_id":"19466ac84a880d70b5ed4a6588eb93bd01ebab23"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"187d137bc3f1defbbe3cc53ff227c84b8a7974e8","unresolved":false,"context_lines":[{"line_number":125,"context_line":""},{"line_number":126,"context_line":"1. If the option ``pbr_major_feature`` is set in setup.cfg to the same"},{"line_number":127,"context_line":"   major and minor components (e.g. last tag is 1.2.3 and pbr_major_feature is"},{"line_number":128,"context_line":"   1.2.1 or just 1.2) then a minor increment is required."},{"line_number":129,"context_line":""},{"line_number":130,"context_line":"1. If the option ``pbr_backwards_incompatible`` is set in setup.cfg to the"},{"line_number":131,"context_line":"   same major component (e.g. last tag is 1.2.3 and pbr_backwards_incompatible"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1ae5cdf2_65ecacc8","line":128,"updated":"2014-06-09 14:40:59.000000000","message":"I\u0027m a little confused about how setting values in the files under revision control will work with using tags for versions. Are these the rules pbr would use for generating new tags? If so, wouldn\u0027t we end up with a setup.cfg containing pbr_major_feature\u003d1.2 in a release tagged 1.3? Does that matter? How do we resolve it?","commit_id":"19466ac84a880d70b5ed4a6588eb93bd01ebab23"},{"author":{"_account_id":4190,"name":"lifeless","email":"robertc@robertcollins.net","username":"lifeless"},"change_message_id":"78b91578bfd8c1a926f3e49437094b67156c04d5","unresolved":false,"context_lines":[{"line_number":125,"context_line":""},{"line_number":126,"context_line":"1. If the option ``pbr_major_feature`` is set in setup.cfg to the same"},{"line_number":127,"context_line":"   major and minor components (e.g. last tag is 1.2.3 and pbr_major_feature is"},{"line_number":128,"context_line":"   1.2.1 or just 1.2) then a minor increment is required."},{"line_number":129,"context_line":""},{"line_number":130,"context_line":"1. If the option ``pbr_backwards_incompatible`` is set in setup.cfg to the"},{"line_number":131,"context_line":"   same major component (e.g. last tag is 1.2.3 and pbr_backwards_incompatible"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1ae5cdf2_d90b9b29","line":128,"updated":"2014-06-09 20:24:49.000000000","message":"That is precisely what we get, and its desired. Since the major feature value will be less than the mos recent tag, it won\u0027t trigger, and no increment would be required by it.","commit_id":"19466ac84a880d70b5ed4a6588eb93bd01ebab23"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"187d137bc3f1defbbe3cc53ff227c84b8a7974e8","unresolved":false,"context_lines":[{"line_number":129,"context_line":""},{"line_number":130,"context_line":"1. If the option ``pbr_backwards_incompatible`` is set in setup.cfg to the"},{"line_number":131,"context_line":"   same major component (e.g. last tag is 1.2.3 and pbr_backwards_incompatible"},{"line_number":132,"context_line":"   is 1.2.1 or 1.2 or just 1) then a major increment is required."},{"line_number":133,"context_line":""},{"line_number":134,"context_line":"1. If the last tag has a major component of 0 then major and minor increments"},{"line_number":135,"context_line":"   are right-shifted. That is a major increment becomes a minor increment and"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1ae5cdf2_e5d7dceb","line":132,"updated":"2014-06-09 14:40:59.000000000","message":"Same question as above; probably the same answer applies. Maybe if you could describe the workflows where these new options are meant to be set it would clarify things?","commit_id":"19466ac84a880d70b5ed4a6588eb93bd01ebab23"},{"author":{"_account_id":4190,"name":"lifeless","email":"robertc@robertcollins.net","username":"lifeless"},"change_message_id":"78b91578bfd8c1a926f3e49437094b67156c04d5","unresolved":false,"context_lines":[{"line_number":129,"context_line":""},{"line_number":130,"context_line":"1. If the option ``pbr_backwards_incompatible`` is set in setup.cfg to the"},{"line_number":131,"context_line":"   same major component (e.g. last tag is 1.2.3 and pbr_backwards_incompatible"},{"line_number":132,"context_line":"   is 1.2.1 or 1.2 or just 1) then a major increment is required."},{"line_number":133,"context_line":""},{"line_number":134,"context_line":"1. If the last tag has a major component of 0 then major and minor increments"},{"line_number":135,"context_line":"   are right-shifted. That is a major increment becomes a minor increment and"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1ae5cdf2_f9069720","line":132,"updated":"2014-06-09 20:24:49.000000000","message":"Will do in the concordance I\u0027ll add.","commit_id":"19466ac84a880d70b5ed4a6588eb93bd01ebab23"},{"author":{"_account_id":4190,"name":"lifeless","email":"robertc@robertcollins.net","username":"lifeless"},"change_message_id":"78b91578bfd8c1a926f3e49437094b67156c04d5","unresolved":false,"context_lines":[{"line_number":151,"context_line":"    no_rc \u003d True"},{"line_number":152,"context_line":"    last_tag \u003d 0.0.0"},{"line_number":153,"context_line":"    tag_distance \u003d 5 # distance to origin"},{"line_number":154,"context_line":"    version \u003d 0.0.1.dev5.gHASH"},{"line_number":155,"context_line":""},{"line_number":156,"context_line":"    tag of 0.12.2 on this commit"},{"line_number":157,"context_line":"    pbr_deprecation \u003d 0.11"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1ae5cdf2_1906e320","line":154,"updated":"2014-06-09 20:24:49.000000000","message":"0.0.1.0a4 - the tagged version. Would you like that added as an example?","commit_id":"19466ac84a880d70b5ed4a6588eb93bd01ebab23"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"187d137bc3f1defbbe3cc53ff227c84b8a7974e8","unresolved":false,"context_lines":[{"line_number":151,"context_line":"    no_rc \u003d True"},{"line_number":152,"context_line":"    last_tag \u003d 0.0.0"},{"line_number":153,"context_line":"    tag_distance \u003d 5 # distance to origin"},{"line_number":154,"context_line":"    version \u003d 0.0.1.dev5.gHASH"},{"line_number":155,"context_line":""},{"line_number":156,"context_line":"    tag of 0.12.2 on this commit"},{"line_number":157,"context_line":"    pbr_deprecation \u003d 0.11"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1ae5cdf2_458330cc","line":154,"updated":"2014-06-09 14:40:59.000000000","message":"What would the version be with no_rc\u003dFalse?","commit_id":"19466ac84a880d70b5ed4a6588eb93bd01ebab23"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"10714b999c314e1efda0a5724b267d6ce053ea90","unresolved":false,"context_lines":[{"line_number":151,"context_line":"    no_rc \u003d True"},{"line_number":152,"context_line":"    last_tag \u003d 0.0.0"},{"line_number":153,"context_line":"    tag_distance \u003d 5 # distance to origin"},{"line_number":154,"context_line":"    version \u003d 0.0.1.dev5.gHASH"},{"line_number":155,"context_line":""},{"line_number":156,"context_line":"    tag of 0.12.2 on this commit"},{"line_number":157,"context_line":"    pbr_deprecation \u003d 0.11"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1ae5cdf2_73a52903","line":154,"in_reply_to":"1ae5cdf2_1906e320","updated":"2014-06-10 12:38:12.000000000","message":"No, I missed that tag comment. The new format makes the examples clearer.","commit_id":"19466ac84a880d70b5ed4a6588eb93bd01ebab23"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"187d137bc3f1defbbe3cc53ff227c84b8a7974e8","unresolved":false,"context_lines":[{"line_number":159,"context_line":""},{"line_number":160,"context_line":"    tag of 0.12.2 2 commits ago"},{"line_number":161,"context_line":"    pbr_deprecation \u003d 0.11"},{"line_number":162,"context_line":"    version \u003d 0.12.3.dev2.gHASH"},{"line_number":163,"context_line":""},{"line_number":164,"context_line":"    tag of 0.12.2 2 commits ago"},{"line_number":165,"context_line":"    pbr_deprecation \u003d 0.12"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1ae5cdf2_05604834","line":162,"updated":"2014-06-09 14:40:59.000000000","message":"Is the pbr_deprecation value actually being used in either of the previous 2 examples? The tag seems more relevant.","commit_id":"19466ac84a880d70b5ed4a6588eb93bd01ebab23"},{"author":{"_account_id":4190,"name":"lifeless","email":"robertc@robertcollins.net","username":"lifeless"},"change_message_id":"78b91578bfd8c1a926f3e49437094b67156c04d5","unresolved":false,"context_lines":[{"line_number":159,"context_line":""},{"line_number":160,"context_line":"    tag of 0.12.2 2 commits ago"},{"line_number":161,"context_line":"    pbr_deprecation \u003d 0.11"},{"line_number":162,"context_line":"    version \u003d 0.12.3.dev2.gHASH"},{"line_number":163,"context_line":""},{"line_number":164,"context_line":"    tag of 0.12.2 2 commits ago"},{"line_number":165,"context_line":"    pbr_deprecation \u003d 0.12"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1ae5cdf2_3901df06","line":162,"updated":"2014-06-09 20:24:49.000000000","message":"The first and second examples show how pbr_deprecation can be an older value without impacting the version when (the question you asked above :)). The third example shows what happens when the pbr_deprecation config item is set to the current major.minor and thus triggers a mandatory minor version bump.","commit_id":"19466ac84a880d70b5ed4a6588eb93bd01ebab23"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"ab10d7c9b1ee6d8eb36c665cd7558a9994c3e803","unresolved":false,"context_lines":[{"line_number":20,"context_line":"release, but often the intent of an untagged commit is to be a developer"},{"line_number":21,"context_line":"version for local installs / testing. So this is not `PEP-440`_ compliant."},{"line_number":22,"context_line":"Conflicting with this is the desire of CD deployers and CD packagers to have"},{"line_number":23,"context_line":"monotonic versions that can be used to install packages on e.g. Debian systems,"},{"line_number":24,"context_line":"but subsequent tags can collide with these versions as well."},{"line_number":25,"context_line":""},{"line_number":26,"context_line":"PEP-440 versions do not map entirely well to version_info - a core python"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1ae5cdf2_1d9dbd59","line":23,"updated":"2014-06-10 20:19:35.000000000","message":"Might as well add/adjust to -\u003e e.g. Debian-based systems (and rpm-based systems).","commit_id":"10cf44f5beefdca93b7799436076442f5e3bfe2e"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"ab10d7c9b1ee6d8eb36c665cd7558a9994c3e803","unresolved":false,"context_lines":[{"line_number":29,"context_line":""},{"line_number":30,"context_line":"Lastly, semver provides deterministic rules for picking the next version number"},{"line_number":31,"context_line":"which at the moment is a developer task. Developers can easily get this wrong"},{"line_number":32,"context_line":"because they\u0027re having to think \u0027what version next\u0027 vs categorising the changes"},{"line_number":33,"context_line":"in the version."},{"line_number":34,"context_line":""},{"line_number":35,"context_line":"In summary:"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1ae5cdf2_9da8ed78","line":32,"updated":"2014-06-10 20:19:35.000000000","message":"+2 I\u0027ve gotten this wrong.","commit_id":"10cf44f5beefdca93b7799436076442f5e3bfe2e"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"ab10d7c9b1ee6d8eb36c665cd7558a9994c3e803","unresolved":false,"context_lines":[{"line_number":82,"context_line":""},{"line_number":83,"context_line":"* Provide a new command to output Debian package version compatible version"},{"line_number":84,"context_line":"  strings.  This primarily involves translating PEP-440 precedence rules into"},{"line_number":85,"context_line":"  Debian ~ and . component separators."},{"line_number":86,"context_line":""},{"line_number":87,"context_line":"* sdist and the new debian version string command will accept a --no-rc"},{"line_number":88,"context_line":"  parameter which will tell them to only ever emit versions that are a) normal"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1ae5cdf2_fd5811fc","line":85,"updated":"2014-06-10 20:19:35.000000000","message":"If we can add a similar section (a new command for rpm versions) that connects/links (maybe to http://zenit.senecac.on.ca/wiki/index.php/ENVRA or similar site describing what the ENVRA format is) I think we can take advantage of the version and release (which are similar to the debian ~ and . components) of rpms to accomplish similar results\n\nIf we need a way to verify rpm versions I have created previously https://gist.github.com/harlowja/6a185742de6d4887efe4 (there might /likely is a be a better way to do this, but this provides a little web UI for people to check versions of rpms and see how the versioning works out).\n\nAnvil https://github.com/stackforge/anvil (one of my other projects) would be happy to use this version number to avoid recomputing the same stuff (anvil builds rpms automatically from the upstream components, so working and easy to use rpm versioning would be awesome). Right now with non-tagged releases the version numbering doesn\u0027t really work (without custom translation from the pbr version).\n\nI\u0027d also recommend we avoid using the epoch functionality of RPMs (or maybe let it be environment variable settable?) and of course the architecture should be \u0027noarch\u0027 (since nothing currently in openstack compiles python c extensions afaik).","commit_id":"10cf44f5beefdca93b7799436076442f5e3bfe2e"},{"author":{"_account_id":4190,"name":"lifeless","email":"robertc@robertcollins.net","username":"lifeless"},"change_message_id":"a0a4dfd727fb4d2c3ea895e68f6228378dd7f53d","unresolved":false,"context_lines":[{"line_number":100,"context_line":"New configuration options/flags"},{"line_number":101,"context_line":"^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^"},{"line_number":102,"context_line":""},{"line_number":103,"context_line":"We are adding some new configuration options."},{"line_number":104,"context_line":""},{"line_number":105,"context_line":"1. ``pbr_deprecation`` set in setup.cfg. This should be set by developers to"},{"line_number":106,"context_line":"   the most recent (in this branch) version in which any API that may be used"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1ae5cdf2_721b501c","line":103,"updated":"2014-06-10 19:47:46.000000000","message":"Actually its the other way around. I forgot to add \u0027developer workflow\u0027, and will do so - but briefly:\n\nsay the last release was 1.2.5\n\nsomeone puts a patch up to deprecate an option. In *that patch* they add/change pbr_deprecation to be 1.2 [patch versions are irrelevant for deprecations]. Before that patch lands, pbr will say the next version is 1.2.6 - so dev builds will be 1.2.6.devN...\n\nOnce the patch lands, pbr will say the next version is 1.3.0 (because a patch version incremental is required due to the deprecation).\n\nWhen the next release is cut, we can use pbrs calculation of the next version to inform our choice (and thus choose 1.3.0 or higher). It might be nice to have a way to ask pbr \u0027whats the next version to use\u0027 without doing sdist + look at the chosen version. That would help with automating, so let me add that to the spec as well.","commit_id":"10cf44f5beefdca93b7799436076442f5e3bfe2e"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"046b15982e43029662ce9348641b04cbcaea3e33","unresolved":false,"context_lines":[{"line_number":100,"context_line":"New configuration options/flags"},{"line_number":101,"context_line":"^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^"},{"line_number":102,"context_line":""},{"line_number":103,"context_line":"We are adding some new configuration options."},{"line_number":104,"context_line":""},{"line_number":105,"context_line":"1. ``pbr_deprecation`` set in setup.cfg. This should be set by developers to"},{"line_number":106,"context_line":"   the most recent (in this branch) version in which any API that may be used"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1ae5cdf2_7713545c","line":103,"updated":"2014-06-10 12:39:56.000000000","message":"It sounds like all of the new configuration options should be set in setup.cfg after tagging the version they specify. We\u0027re not, for example, saying \"the release we\u0027re about to tag will be deprecating/adding/changing a feature\" but instead \"an earlier release contains a feature which is deprecated/new/changed\". Is that right? If so, creating a release now may include 2 steps: tag the release and then (possibly) land a commit updating one or more of these settings before any other commits (so the CD numbering with --no-rc doesn\u0027t get messed up). Maybe the race condition is only there for alpha releases, which technically shouldn\u0027t have any changes in these flags between alpha versions.","commit_id":"10cf44f5beefdca93b7799436076442f5e3bfe2e"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"ab10d7c9b1ee6d8eb36c665cd7558a9994c3e803","unresolved":false,"context_lines":[{"line_number":269,"context_line":"Primary assignee:"},{"line_number":270,"context_line":"  Robert Collins (lifeless)"},{"line_number":271,"context_line":""},{"line_number":272,"context_line":"Other contributors:"},{"line_number":273,"context_line":"  Anyone I can rope in."},{"line_number":274,"context_line":""},{"line_number":275,"context_line":"Milestones"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1ae5cdf2_1db4ddcf","line":272,"updated":"2014-06-10 20:19:35.000000000","message":"U can add me if u dare :-P","commit_id":"10cf44f5beefdca93b7799436076442f5e3bfe2e"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"ab10d7c9b1ee6d8eb36c665cd7558a9994c3e803","unresolved":false,"context_lines":[{"line_number":290,"context_line":""},{"line_number":291,"context_line":"* Add tagging feature."},{"line_number":292,"context_line":""},{"line_number":293,"context_line":"* Add debian-version feature."},{"line_number":294,"context_line":""},{"line_number":295,"context_line":"* Add version_info feature."},{"line_number":296,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"1ae5cdf2_3dca794f","line":293,"updated":"2014-06-10 20:19:35.000000000","message":"Add rpm-version feature.","commit_id":"10cf44f5beefdca93b7799436076442f5e3bfe2e"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"ab10d7c9b1ee6d8eb36c665cd7558a9994c3e803","unresolved":false,"context_lines":[{"line_number":312,"context_line":"Anticipated API Stabilization"},{"line_number":313,"context_line":"-----------------------------"},{"line_number":314,"context_line":""},{"line_number":315,"context_line":"None. It shall be perfect."},{"line_number":316,"context_line":""},{"line_number":317,"context_line":"Documentation Impact"},{"line_number":318,"context_line":"\u003d\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":3,"id":"1ae5cdf2_7d6c019d","line":315,"updated":"2014-06-10 20:19:35.000000000","message":"+2 ;)","commit_id":"10cf44f5beefdca93b7799436076442f5e3bfe2e"},{"author":{"_account_id":4190,"name":"lifeless","email":"robertc@robertcollins.net","username":"lifeless"},"change_message_id":"865f9db9dfc6b6bbd5d400b12aa7cd8e543301ee","unresolved":false,"context_lines":[{"line_number":56,"context_line":"  tagging them as 1.2.3.0a4 instead, and update the semver docs accordingly."},{"line_number":57,"context_line":"  This gets us PEP440 compatibility. We need to continue accepting the current"},{"line_number":58,"context_line":"  format tags since they already exist on our branches - but we can emit"},{"line_number":59,"context_line":"  deprecation warnings."},{"line_number":60,"context_line":""},{"line_number":61,"context_line":"* Add metadata fields to setup.cfg to allow recording the last release that"},{"line_number":62,"context_line":"  had been made when a backwards incompatible change was made, or when a"}],"source_content_type":"text/x-rst","patch_set":4,"id":"1ae5cdf2_577ef419","line":59,"updated":"2014-06-12 19:11:32.000000000","message":"Ah. Good question. Best answer I have is for easier compatibility with Debian etc tools, but *obviously* we\u0027re going to do that by emitting debian versions ourselves, directly. So, indeed, not needed. I will revise the whole spec accordingly. We\u0027ll want to describe somewhere in the docs how we\u0027re mapping semver.rst to PEP-440.","commit_id":"392050f931b76b2358d4cf637b34c9987df9b5e5"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"13cfc76035cda0b6c53dbf9d6e361774b1e5db8d","unresolved":false,"context_lines":[{"line_number":56,"context_line":"  tagging them as 1.2.3.0a4 instead, and update the semver docs accordingly."},{"line_number":57,"context_line":"  This gets us PEP440 compatibility. We need to continue accepting the current"},{"line_number":58,"context_line":"  format tags since they already exist on our branches - but we can emit"},{"line_number":59,"context_line":"  deprecation warnings."},{"line_number":60,"context_line":""},{"line_number":61,"context_line":"* Add metadata fields to setup.cfg to allow recording the last release that"},{"line_number":62,"context_line":"  had been made when a backwards incompatible change was made, or when a"}],"source_content_type":"text/x-rst","patch_set":4,"id":"1ae5cdf2_31ae0699","line":59,"updated":"2014-06-11 14:31:36.000000000","message":"The PEP includes many examples like 1.2.3a4. Why do we need the extra digit? Why 1.2.3.0a4 instead of 1.2.3a4?","commit_id":"392050f931b76b2358d4cf637b34c9987df9b5e5"},{"author":{"_account_id":2,"name":"Monty Taylor","email":"mordred@inaugust.com","username":"mordred"},"change_message_id":"f69b9f4e26f4ea31e5c361ee26c9d486befe9cfc","unresolved":false,"context_lines":[{"line_number":56,"context_line":"  tagging them as 1.2.3.0a4 instead, and update the semver docs accordingly."},{"line_number":57,"context_line":"  This gets us PEP440 compatibility. We need to continue accepting the current"},{"line_number":58,"context_line":"  format tags since they already exist on our branches - but we can emit"},{"line_number":59,"context_line":"  deprecation warnings."},{"line_number":60,"context_line":""},{"line_number":61,"context_line":"* Add metadata fields to setup.cfg to allow recording the last release that"},{"line_number":62,"context_line":"  had been made when a backwards incompatible change was made, or when a"}],"source_content_type":"text/x-rst","patch_set":4,"id":"1ae5cdf2_9bcf907e","line":59,"in_reply_to":"1ae5cdf2_577ef419","updated":"2014-06-14 21:15:42.000000000","message":"I believe we should not pollute the third number. Upstream semver, even though we\u0027re going to disagree on how to deal with suffixes, communicates a three-meaningful-numbers strategy. I think it\u0027s very odd to attach an a to one of those, even though it\u0027s pep440 compliant.","commit_id":"392050f931b76b2358d4cf637b34c9987df9b5e5"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"85ceb7a38bf3a13993e6601af56c5c49357c04ac","unresolved":false,"context_lines":[{"line_number":90,"context_line":"  pre-release and dev builds as release builds of next lowest version to drive"},{"line_number":91,"context_line":"  the sort order above all actual releases of the version below. We assume that"},{"line_number":92,"context_line":"  no version will ever have more than 9998 patch/minor releases.  E.g."},{"line_number":93,"context_line":"  1.2.0.dev5 is rendered as 1.1.9999.dev5. 1.0.0.dev5 would be rendered as"},{"line_number":94,"context_line":"  0.0.9999.dev5 and finally 0.0.0.dev5 would also be rendered as 0.0.0.dev5 to"},{"line_number":95,"context_line":"  avoid negative version numbers."},{"line_number":96,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"1ae5cdf2_be8f5f22","line":93,"updated":"2014-06-10 21:43:24.000000000","message":"I think u might want to render this as the following:\n\n1.2.0.dev5 -\u003e 1.2.0-dev5 (dev5 being the release?)\n\n1.1.9999.dev5 -\u003e 1.1.9999-dev5 (accordingly)\n\nOtherwise seems ok and did a quick check with rpm comparison tool and seems to compare correctly.\n\n  \u0027nova-1.1.9999-dev6.rhel.x86_64.rpm\u0027 is newer than \u0027nova-1.1.9999-dev5.rhel.x86_64.rpm\u0027\n\n  \u0027nova-1.2.0-dev5.rhel.x86_64.rpm\u0027 is newer than \u0027nova-1.1.9999-dev5.rhel.x86_64.rpm\u0027\n\n  \u0027nova-1.1.1-dev5.rhel.x86_64.rpm\u0027 is older than \u0027nova-1.1.9999-dev5.rhel.x86_64.rpm\u0027","commit_id":"392050f931b76b2358d4cf637b34c9987df9b5e5"},{"author":{"_account_id":4190,"name":"lifeless","email":"robertc@robertcollins.net","username":"lifeless"},"change_message_id":"865f9db9dfc6b6bbd5d400b12aa7cd8e543301ee","unresolved":false,"context_lines":[{"line_number":90,"context_line":"  pre-release and dev builds as release builds of next lowest version to drive"},{"line_number":91,"context_line":"  the sort order above all actual releases of the version below. We assume that"},{"line_number":92,"context_line":"  no version will ever have more than 9998 patch/minor releases.  E.g."},{"line_number":93,"context_line":"  1.2.0.dev5 is rendered as 1.1.9999.dev5. 1.0.0.dev5 would be rendered as"},{"line_number":94,"context_line":"  0.0.9999.dev5 and finally 0.0.0.dev5 would also be rendered as 0.0.0.dev5 to"},{"line_number":95,"context_line":"  avoid negative version numbers."},{"line_number":96,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"1ae5cdf2_7779302e","line":93,"updated":"2014-06-12 19:11:32.000000000","message":"Ok so its good to provoke discussion. Have you read \u0027semver.rst\u0027 in the pbr docs? If not, you\u0027ll want to.\n\nBut - here goes - we need to emit the following versions:\n1.2.0, 1.2.0.rcN, 1.2.0.bN, 1.2.0.aN, 1.2.0.devN\n\nWith the following rules:\n 1.2.0 \u003e (1.2.0.rcN, 1.2.0.bN, 1.2.0.aN, 1.2.0.devN)\n 1.2.0.rcN \u003e (1.2.0.bN, 1.2.0.aN)\n 1.2.0.bN \u003e 1.2.0.aN\n\nNote that for any aN, it should be \u003e a(N-1); also note that we do not need to have particular sort order between the devN and the aN/bN/rcN versions.\n\nSo I propose the following test matrix - for each pair below, A should be greater than B, then we can run different serialisers through your version compare tool. I think I\u0027ve covered all the permutations. I don\u0027t know enough about RPM to have any real input to the algorithm, but the ENVRA page suggests that the release is the packager (the RPM packagers) territory - if its ok to use that, cool.\n\n A, B\n 1.2.0     1.2.0a2\n 1.2.0     1.2.0b2\n 1.2.0     1.2.0rc2\n 1.2.0     1.2.0dev2\n 1.2.0     1.1.0\n 1.2.0rc2  1.2.0a2\n 1.2.0rc2  1.2.0b2\n 1.2.0rc2  1.1.0\n 1.2.0b2   1.2.0a2\n 1.2.0b2   1.1.0\n 1.2.0a2   1.1.0\n 1.2.0dev2 1.1.0\n\nIf those relations all hold, I think we\u0027re in good shape.","commit_id":"392050f931b76b2358d4cf637b34c9987df9b5e5"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"0e99ba6a85a0a41102145475930707cad9febd04","unresolved":false,"context_lines":[{"line_number":90,"context_line":"  pre-release and dev builds as release builds of next lowest version to drive"},{"line_number":91,"context_line":"  the sort order above all actual releases of the version below. We assume that"},{"line_number":92,"context_line":"  no version will ever have more than 9998 patch/minor releases.  E.g."},{"line_number":93,"context_line":"  1.2.0.dev5 is rendered as 1.1.9999.dev5. 1.0.0.dev5 would be rendered as"},{"line_number":94,"context_line":"  0.0.9999.dev5 and finally 0.0.0.dev5 would also be rendered as 0.0.0.dev5 to"},{"line_number":95,"context_line":"  avoid negative version numbers."},{"line_number":96,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"1ae5cdf2_d1faa642","line":93,"in_reply_to":"1ae5cdf2_7779302e","updated":"2014-06-16 23:13:09.000000000","message":"So here is a little script that tests this:\n\nhttps://gist.github.com/harlowja/b3ec3dcf6dd51cc67636 (the simple algorithm for converting can be found in here). Any system with yum package can be used to run that.\n\nThe output of running:\n\nTesting 1.2.0, 1.2.0.a2\n  * test - 1.2.0-0.noarch\n  * test - 1.2.0-a2.noarch\nResults: 1.2.0.a2 is older than 1.2.0\nTesting 1.2.0, 1.2.0.b2\n  * test - 1.2.0-0.noarch\n  * test - 1.2.0-b2.noarch\nResults: 1.2.0.b2 is older than 1.2.0\nTesting 1.2.0, 1.2.0.rc2\n  * test - 1.2.0-0.noarch\n  * test - 1.2.0-rc2.noarch\nResults: 1.2.0.rc2 is older than 1.2.0\nTesting 1.2.0, 1.2.0.dev2\n  * test - 1.2.0-0.noarch\n  * test - 1.2.0-dev2.noarch\nResults: 1.2.0.dev2 is older than 1.2.0\nTesting 1.2.0, 1.1.0\n  * test - 1.2.0-0.noarch\n  * test - 1.1.0-0.noarch\nResults: 1.1.0 is older than 1.2.0\nTesting 1.2.0.rc2, 1.2.0.a2\n  * test - 1.2.0-rc2.noarch\n  * test - 1.2.0-a2.noarch\nResults: 1.2.0.a2 is older than 1.2.0.rc2\nTesting 1.2.0.rc2, 1.2.0.b2\n  * test - 1.2.0-rc2.noarch\n  * test - 1.2.0-b2.noarch\nResults: 1.2.0.b2 is older than 1.2.0.rc2\nTesting 1.2.0.rc2, 1.1.0\n  * test - 1.2.0-rc2.noarch\n  * test - 1.1.0-0.noarch\nResults: 1.1.0 is older than 1.2.0.rc2\nTesting 1.2.0.b2, 1.2.0.a2\n  * test - 1.2.0-b2.noarch\n  * test - 1.2.0-a2.noarch\nResults: 1.2.0.a2 is older than 1.2.0.b2\nTesting 1.2.0.b2, 1.1.0\n  * test - 1.2.0-b2.noarch\n  * test - 1.1.0-0.noarch\nResults: 1.1.0 is older than 1.2.0.b2\nTesting 1.2.0.a2, 1.1.0\n  * test - 1.2.0-a2.noarch\n  * test - 1.1.0-0.noarch\nResults: 1.1.0 is older than 1.2.0.a2\nTesting 1.2.0.dev2, 1.1.0\n  * test - 1.2.0-dev2.noarch\n  * test - 1.1.0-0.noarch\nResults: 1.1.0 is older than 1.2.0.dev2\n\nI think the relations hold up as expected (correct me if I am wrong).","commit_id":"392050f931b76b2358d4cf637b34c9987df9b5e5"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"2f29ddb6cda356eb0f8f5afd14277689e2a4b704","unresolved":false,"context_lines":[{"line_number":241,"context_line":"and there is no ability to reuse their solutions in a systematic fashion."},{"line_number":242,"context_line":""},{"line_number":243,"context_line":"We could put deprecated etc markers in setup.cfg (see previous iterations of"},{"line_number":244,"context_line":"this spec in gerrit). This was felt to be too tedious to maintain."},{"line_number":245,"context_line":""},{"line_number":246,"context_line":"Impact on Existing APIs"},{"line_number":247,"context_line":"-----------------------"}],"source_content_type":"text/x-rst","patch_set":8,"id":"1ae5cdf2_e7df1764","line":244,"updated":"2014-06-15 14:23:01.000000000","message":"Yes, this new version is much easier to follow, too.","commit_id":"7d1de37e0ddd6a47fd2c5cabca87faa555ac0984"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"2f29ddb6cda356eb0f8f5afd14277689e2a4b704","unresolved":false,"context_lines":[{"line_number":325,"context_line":"----------"},{"line_number":326,"context_line":""},{"line_number":327,"context_line":"Target Milestone for completion:"},{"line_number":328,"context_line":"  Juno-1"},{"line_number":329,"context_line":""},{"line_number":330,"context_line":"Work Items"},{"line_number":331,"context_line":"----------"}],"source_content_type":"text/x-rst","patch_set":8,"id":"1ae5cdf2_47f1abff","line":328,"updated":"2014-06-15 14:23:01.000000000","message":"Juno-2","commit_id":"7d1de37e0ddd6a47fd2c5cabca87faa555ac0984"},{"author":{"_account_id":6849,"name":"Roman Podoliaka","email":"roman.podoliaka@gmail.com","username":"rpodolyaka"},"change_message_id":"dea408169a0462d7bcde4ca98550ee097d1983d9","unresolved":false,"context_lines":[{"line_number":74,"context_line":"* For untagged builds, generate devN versions - e.g.  x.y.z.dev4+gHASH, where"},{"line_number":75,"context_line":"  x.y.z are derived by applying the semver rules with the metadata about the"},{"line_number":76,"context_line":"  most recent change of each type. For pre-versioned builds, we will also"},{"line_number":77,"context_line":"  generate devN builds but will not apply semver rules. THe +gHASH is driven"},{"line_number":78,"context_line":"  by PEP-440, and will be slightly syntax incompatible with upstream semver,"},{"line_number":79,"context_line":"  but we think this is the right tradeoff. Semantically it is compatible."},{"line_number":80,"context_line":""}],"source_content_type":"text/x-rst","patch_set":9,"id":"1ae5cdf2_648745b7","line":77,"updated":"2014-06-17 09:23:50.000000000","message":"nit: The","commit_id":"c3ae7191da69a003c0b0a58c606c03ad30c9bd4e"},{"author":{"_account_id":4146,"name":"Clark Boylan","email":"cboylan@sapwetik.org","username":"cboylan"},"change_message_id":"6a001e7b894bef1207e094f765af2688ca71087f","unresolved":false,"context_lines":[{"line_number":78,"context_line":"  by PEP-440, and will be slightly syntax incompatible with upstream semver,"},{"line_number":79,"context_line":"  but we think this is the right tradeoff. Semantically it is compatible."},{"line_number":80,"context_line":""},{"line_number":81,"context_line":"* Provide a new command to do the git tagging for developers. It will accept"},{"line_number":82,"context_line":"  parameters allowing manual control, but will enforce semver is being followed"},{"line_number":83,"context_line":"  (e.g. if there is a newer tag than the version being tagged in the history of"},{"line_number":84,"context_line":"  the branch, thats an error). Alpha, beta and rc tagging can be automated too."}],"source_content_type":"text/x-rst","patch_set":9,"id":"1ae5cdf2_94061120","line":81,"updated":"2014-06-18 00:39:25.000000000","message":"Below the new commands are explicitly called out. Might be nice to do that here as well.","commit_id":"c3ae7191da69a003c0b0a58c606c03ad30c9bd4e"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"a7a7f79c2bc3c3e25f8992e7d1996818f3e8fb62","unresolved":false,"context_lines":[{"line_number":107,"context_line":"* Provide a new command (``next-version``) to output the next calculated semver"},{"line_number":108,"context_line":"  version. E.g. if the last release was 1.2.3 but backwards incompatibility has"},{"line_number":109,"context_line":"  happened, this command would output 2.0.0. The expected use of this command"},{"line_number":110,"context_line":"  is to aid developers choose the next version to tag."},{"line_number":111,"context_line":""},{"line_number":112,"context_line":"* sdist and the new Debian and RPM version string commands will accept a"},{"line_number":113,"context_line":"  ``--no-rc`` parameter which will tell them to only ever emit versions that"}],"source_content_type":"text/x-rst","patch_set":9,"id":"1ae5cdf2_1e66e0ee","line":110,"updated":"2014-06-16 19:46:06.000000000","message":"Very nice. This will help out alot.","commit_id":"c3ae7191da69a003c0b0a58c606c03ad30c9bd4e"},{"author":{"_account_id":6849,"name":"Roman Podoliaka","email":"roman.podoliaka@gmail.com","username":"rpodolyaka"},"change_message_id":"dea408169a0462d7bcde4ca98550ee097d1983d9","unresolved":false,"context_lines":[{"line_number":107,"context_line":"* Provide a new command (``next-version``) to output the next calculated semver"},{"line_number":108,"context_line":"  version. E.g. if the last release was 1.2.3 but backwards incompatibility has"},{"line_number":109,"context_line":"  happened, this command would output 2.0.0. The expected use of this command"},{"line_number":110,"context_line":"  is to aid developers choose the next version to tag."},{"line_number":111,"context_line":""},{"line_number":112,"context_line":"* sdist and the new Debian and RPM version string commands will accept a"},{"line_number":113,"context_line":"  ``--no-rc`` parameter which will tell them to only ever emit versions that"}],"source_content_type":"text/x-rst","patch_set":9,"id":"1ae5cdf2_a42dcdaa","line":110,"in_reply_to":"1ae5cdf2_1e66e0ee","updated":"2014-06-17 09:23:50.000000000","message":"Automation! \\o/","commit_id":"c3ae7191da69a003c0b0a58c606c03ad30c9bd4e"},{"author":{"_account_id":6849,"name":"Roman Podoliaka","email":"roman.podoliaka@gmail.com","username":"rpodolyaka"},"change_message_id":"dea408169a0462d7bcde4ca98550ee097d1983d9","unresolved":false,"context_lines":[{"line_number":155,"context_line":"not semver versions, and because their definition is \u0027the user has chosen\u0027,"},{"line_number":156,"context_line":"it is out of scope for now."},{"line_number":157,"context_line":""},{"line_number":158,"context_line":"1. If there are one or more tags for a commit then the highest such tag is"},{"line_number":159,"context_line":"    considered to be the \u0027last tag\u0027 for these rules."},{"line_number":160,"context_line":""},{"line_number":161,"context_line":"1. If the last tag is a pre-release tag, then the --no-rc option is consulted."}],"source_content_type":"text/x-rst","patch_set":9,"id":"1ae5cdf2_f3d6b852","line":158,"updated":"2014-06-17 09:23:50.000000000","message":"nit: enumeration is not rendered as 1, 2, 3.. but rather as 1, 1, 1..","commit_id":"c3ae7191da69a003c0b0a58c606c03ad30c9bd4e"},{"author":{"_account_id":4146,"name":"Clark Boylan","email":"cboylan@sapwetik.org","username":"cboylan"},"change_message_id":"6a001e7b894bef1207e094f765af2688ca71087f","unresolved":false,"context_lines":[{"line_number":167,"context_line":"   and a final tag on a single commit) then the highest tag is still used. If"},{"line_number":168,"context_line":"   there is no tag reachable at all, ``0.0.0`` is implied as the last tag."},{"line_number":169,"context_line":"   Tags are eligible if they are PEP-440 version strings, reachable from the"},{"line_number":170,"context_line":""},{"line_number":171,"context_line":"   commit in the git history, and not excluded by the --no-rc option."},{"line_number":172,"context_line":""},{"line_number":173,"context_line":"1. If the distance to the last tag is zero, that tag supplies the version and"}],"source_content_type":"text/x-rst","patch_set":9,"id":"1ae5cdf2_ef7300b2","line":170,"updated":"2014-06-18 00:39:25.000000000","message":"This blank line is funny.","commit_id":"c3ae7191da69a003c0b0a58c606c03ad30c9bd4e"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"a7a7f79c2bc3c3e25f8992e7d1996818f3e8fb62","unresolved":false,"context_lines":[{"line_number":173,"context_line":"1. If the distance to the last tag is zero, that tag supplies the version and"},{"line_number":174,"context_line":"   the process stops."},{"line_number":175,"context_line":""},{"line_number":176,"context_line":"1. Otherwise, a patch level version is required and the version shall be a "},{"line_number":177,"context_line":"   devN version."},{"line_number":178,"context_line":""},{"line_number":179,"context_line":"1. We then ask git for all the commts leading back to the last tag."}],"source_content_type":"text/x-rst","patch_set":9,"id":"1ae5cdf2_1ec26086","line":176,"updated":"2014-06-16 19:46:06.000000000","message":"Eck, redness.","commit_id":"c3ae7191da69a003c0b0a58c606c03ad30c9bd4e"},{"author":{"_account_id":6928,"name":"Ben Nemec","email":"openstack@nemebean.com","username":"bnemec"},"change_message_id":"8c8cfc5d29f7eda2a7e0c6dd119638d092707f90","unresolved":false,"context_lines":[{"line_number":176,"context_line":"1. Otherwise, a patch level version is required and the version shall be a "},{"line_number":177,"context_line":"   devN version."},{"line_number":178,"context_line":""},{"line_number":179,"context_line":"1. We then ask git for all the commts leading back to the last tag."},{"line_number":180,"context_line":""},{"line_number":181,"context_line":"1. In each commit we look for a sem-ver: pseudo header, and if found"},{"line_number":182,"context_line":"   parse it (split on \u0027,\u0027 whitespace strip and build a set). Unknown"}],"source_content_type":"text/x-rst","patch_set":9,"id":"1ae5cdf2_d1f0e693","line":179,"updated":"2014-06-16 23:22:51.000000000","message":"*commits","commit_id":"c3ae7191da69a003c0b0a58c606c03ad30c9bd4e"},{"author":{"_account_id":6928,"name":"Ben Nemec","email":"openstack@nemebean.com","username":"bnemec"},"change_message_id":"8c8cfc5d29f7eda2a7e0c6dd119638d092707f90","unresolved":false,"context_lines":[{"line_number":270,"context_line":"Developer Impact"},{"line_number":271,"context_line":"----------------"},{"line_number":272,"context_line":""},{"line_number":273,"context_line":"Developers can largely ignore this - it will just result in PEP-440"},{"line_number":274,"context_line":"compatible versions. If a project wants to opt into the new features they"},{"line_number":275,"context_line":"can do so: export version_info tuples in their projects, record when they"},{"line_number":276,"context_line":"make breaking changes and have pbr enforce appropriate version changes for"}],"source_content_type":"text/x-rst","patch_set":9,"id":"1ae5cdf2_d17546fb","line":273,"updated":"2014-06-16 23:22:51.000000000","message":"I\u0027m guessing this is left over from a previous iteration, because developers are going to have to tag their deprecating/api breaking commits now.","commit_id":"c3ae7191da69a003c0b0a58c606c03ad30c9bd4e"},{"author":{"_account_id":4146,"name":"Clark Boylan","email":"cboylan@sapwetik.org","username":"cboylan"},"change_message_id":"6a001e7b894bef1207e094f765af2688ca71087f","unresolved":false,"context_lines":[{"line_number":270,"context_line":"Developer Impact"},{"line_number":271,"context_line":"----------------"},{"line_number":272,"context_line":""},{"line_number":273,"context_line":"Developers can largely ignore this - it will just result in PEP-440"},{"line_number":274,"context_line":"compatible versions. If a project wants to opt into the new features they"},{"line_number":275,"context_line":"can do so: export version_info tuples in their projects, record when they"},{"line_number":276,"context_line":"make breaking changes and have pbr enforce appropriate version changes for"}],"source_content_type":"text/x-rst","patch_set":9,"id":"1ae5cdf2_8f451c17","line":273,"in_reply_to":"1ae5cdf2_d17546fb","updated":"2014-06-18 00:39:25.000000000","message":"This should be addressed as it may be misleading to a dev that skips to the developer impact section and moves on when they are told they can ignore this.","commit_id":"c3ae7191da69a003c0b0a58c606c03ad30c9bd4e"},{"author":{"_account_id":1955,"name":"Alan Pevec","email":"alan.pevec@redhat.com","username":"apevec"},"change_message_id":"d25cdf5dc58c1ce16cc85a09fa3a391e9a419a8d","unresolved":false,"context_lines":[{"line_number":232,"context_line":"    pbr_deprecation \u003d 1.12"},{"line_number":233,"context_line":"    version \u003d 1.13.0.dev2+gHASH"},{"line_number":234,"context_line":"    Debian version \u003d 0.13.0~dev2+gHASH"},{"line_number":235,"context_line":"    RPM version \u003d 0.12.9999.dev2+gHASH"},{"line_number":236,"context_line":""},{"line_number":237,"context_line":"Alternatives"},{"line_number":238,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":10,"id":"1ae5cdf2_e528d335","line":235,"updated":"2014-06-23 19:06:20.000000000","message":"FWIW Fedora prerelease naming guidline[1] uses 0.* in Release RPM field so Fedora-compliant version-release for this example would be 0.13.0-0.dev2+gHASH\n\n[1] https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Pre-Release_packages","commit_id":"8394284cb3104a82a91f5c3b3d0a0cf0ed1f26f8"},{"author":{"_account_id":1955,"name":"Alan Pevec","email":"alan.pevec@redhat.com","username":"apevec"},"change_message_id":"19c3ef8668d4673414a774b8ff14f3cf24ac4630","unresolved":false,"context_lines":[{"line_number":232,"context_line":"    pbr_deprecation \u003d 1.12"},{"line_number":233,"context_line":"    version \u003d 1.13.0.dev2+gHASH"},{"line_number":234,"context_line":"    Debian version \u003d 0.13.0~dev2+gHASH"},{"line_number":235,"context_line":"    RPM version \u003d 0.12.9999.dev2+gHASH"},{"line_number":236,"context_line":""},{"line_number":237,"context_line":"Alternatives"},{"line_number":238,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":10,"id":"1ae5cdf2_5697e444","line":235,"in_reply_to":"1ae5cdf2_9c5f3ce4","updated":"2014-06-27 06:23:34.000000000","message":"Release field 0.* is ok for pre-releases only, after release it is bumped for each rebuild e.g. changelog for Fedora openstack-keystone package[1]\n\nEpoch should be avoided, once introduced in a package you have to supply it everywhere. They need to be used only when upstream versioning changes, like it happened with OpenStack clients[2]\n\n\n[1] http://pkgs.fedoraproject.org/cgit/openstack-keystone.git/tree/openstack-keystone.spec?id\u003d216d357efd425c90507bae0b304dc614f9886220#n230\n\n[2] http://pkgs.fedoraproject.org/cgit/python-keystoneclient.git/commit/?id\u003d97a166915880a232151248ea0977ecec102ebf0f","commit_id":"8394284cb3104a82a91f5c3b3d0a0cf0ed1f26f8"},{"author":{"_account_id":1297,"name":"Joshua Harlow","email":"jxharlow@godaddy.com","username":"harlowja"},"change_message_id":"9431c19aea94da71901477b11516e49706a064c8","unresolved":false,"context_lines":[{"line_number":232,"context_line":"    pbr_deprecation \u003d 1.12"},{"line_number":233,"context_line":"    version \u003d 1.13.0.dev2+gHASH"},{"line_number":234,"context_line":"    Debian version \u003d 0.13.0~dev2+gHASH"},{"line_number":235,"context_line":"    RPM version \u003d 0.12.9999.dev2+gHASH"},{"line_number":236,"context_line":""},{"line_number":237,"context_line":"Alternatives"},{"line_number":238,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":10,"id":"1ae5cdf2_9c5f3ce4","line":235,"in_reply_to":"1ae5cdf2_e528d335","updated":"2014-06-24 16:59:49.000000000","message":"Thanks, I think its fine to do that. Is it ok to use the release field in general (as long as we stick to 0.*)? If so that will be helpful in the future and would be great to clarify upfront.\n\nAny thoughts on the epoch we should be setting to (I assume by default 0 epoch)? Will that work out for fedora?","commit_id":"8394284cb3104a82a91f5c3b3d0a0cf0ed1f26f8"}]}