[#1872] version.txt: increment to 0.17.0

[andrey-utkin]

This is to make it possible to differentiate between 0.16.0 and current master. A specific case where this is needed is the CI problems with ruby-rnp test suite in the PR backporting specific features onto 0.16.0 to make a 0.16.1: https://github.com/rnpgp/rnp/pull/1869

This should be merged at the same time with a change for ruby-rnp: https://github.com/rnpgp/ruby-rnp/pull/81

Bug: https://github.com/rnpgp/rnp/issues/1872

[codecov[bot]]

Codecov Report

Merging #1873 (9e3bdf9) into master (47221ae) will not change coverage. The diff coverage is n/a.

:exclamation: Current head 9e3bdf9 differs from pull request most recent head 0a5cdf4. Consider uploading reports for the commit 0a5cdf4 to get more accurate results

@@           Coverage Diff           @@
##           master    #1873   +/-   ##
=======================================
  Coverage   81.54%   81.54%           
=======================================
  Files         138      138           
  Lines       28917    28917           
=======================================
  Hits        23580    23580           
  Misses       5337     5337           

---

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update 47221ae...0a5cdf4. Read the comment docs.

[andrey-utkin]

Fine, but we still need to somehow tell the release from a master branch. A couple other ways I see here. Does any of them look good to you?

1. Make the master branch have the semblance of "unstable release branch", with odd minor number, e.g. 0.17.x, then when there's time to branch from that, convert it to the even-numbered 0.18.x.

2. A special token in version.txt on live branches. For example, ffmpeg does it this way: As a part of release branching procedure, right after the branching, the value of RELEASE file changes from 4.2.git to 4.3.git for master and 4.2 for the release branch. https://git.ffmpeg.org/gitweb/ffmpeg.git/blobdiff/1ee3c984b91e0241068d1c093d222ecec2e6052c..f66f3ca2c18f00bf4fc17f7a5d346abb78be41de:/RELEASE https://git.ffmpeg.org/gitweb/ffmpeg.git/blobdiff/0a8a96c25194b550f3b87902e1b7f061738ae3cd..c1ebaffba9fdc8948bce54b96c347ff960d1440c:/RELEASE

[ronaldtse]

We're trying to release 0.16.1, so it is reasonable to have 0.16 right now.

I think this is a reasonable approach:

A special token in version.txt on live branches. For example, ffmpeg does it this way: As a part of release branching procedure, right after the branching, the value of RELEASE file changes from 4.2.git to 4.3.git for master and 4.2 for the release branch.

[ni4]

In this particular case we got problems on ruby-rnp side since planned next version was v0.17.0. Having knowledge that key expiration time commits would be included into v0.16.1, we may just fix https://github.com/rnpgp/ruby-rnp/pull/81/files with the Rnp.version >= Rnp.version("0.16.1") check.

[andrey-utkin]

In this particular case we got problems on ruby-rnp side since planned next version was v0.17.0. Having knowledge that key expiration time commits would be included into v0.16.1, we may just fix https://github.com/rnpgp/ruby-rnp/pull/81/files with the Rnp.version >= Rnp.version("0.16.1") check.

While this would fix it for v0.16.1 and its descendants, it won't fix it for release/0.x branch and any PRs targeting it, which ties our hands in preparing the release.

[ni4]

In this particular case we got problems on ruby-rnp side since planned next version was v0.17.0. Having knowledge that key expiration time commits would be included into v0.16.1, we may just fix https://github.com/rnpgp/ruby-rnp/pull/81/files with the Rnp.version >= Rnp.version("0.16.1") check.

While this would fix it for v0.16.1 and its descendants, it won't fix it for release/0.x branch and any PRs targeting it, which ties our hands in preparing the release.

But how in practice we could need something inbetween v0.16.0 and v0.16.1?

[andrey-utkin]

But how in practice we could need something inbetween v0.16.0 and v0.16.1?

During release preparation, for example, for PRs backporting individual features.

[ronaldtse]

But how in practice we could need something inbetween v0.16.0 and v0.16.1?

During release preparation, for example, for PRs backporting individual features.

Agree.

[ni4]

Closing this as it was handled in a different way.