Release v0.16.1

[ni4]

As title says. Should wait till PR #1885 is resolved, as well as possible CI failures.

[lgtm-com[bot]]

This pull request fixes 1 alert when merging b57b0340fa10b259c9e1f39fefdf08b9c47f881d into f06439f77e50974e427023f77a459843e46ac682 - view on LGTM.com

fixed alerts:

• 1 for Mismatching new/free or malloc/delete

[codecov[bot]]

Codecov Report

Merging #1886 (7cf2be9) into release/0.x (f06439f) will increase coverage by 1.49%. The diff coverage is 85.82%.

@@               Coverage Diff               @@
##           release/0.x    #1886      +/-   ##
===============================================
+ Coverage        80.20%   81.70%   +1.49%     
===============================================
  Files              133      140       +7     
  Lines            28868    28944      +76     
===============================================
+ Hits             23154    23648     +494     
+ Misses            5714     5296     -418     

Impacted Files	Coverage Δ
src/examples/sign.c	70.00% <0.00%> (ø)
src/lib/crypto/dsa.cpp	76.11% <ø> (ø)
src/lib/crypto/ecdh_utils.cpp	90.00% <ø> (-2.00%)	:arrow_down:
src/lib/crypto/mpi.cpp	94.73% <ø> (ø)
src/lib/crypto/rsa.cpp	78.35% <ø> (ø)
src/lib/crypto/symmetric.cpp	83.78% <ø> (-0.78%)	:arrow_down:
src/lib/pgp-key.h	90.90% <ø> (ø)
src/lib/types.h	100.00% <ø> (ø)
src/librekey/g10_sexp.hpp	88.88% <ø> (ø)
src/librepgp/stream-ctx.h	100.00% <ø> (ø)
... and 112 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[lgtm-com[bot]]

This pull request fixes 1 alert when merging 1f13e0d6e8b74638de9383e166596f4285a422a4 into f06439f77e50974e427023f77a459843e46ac682 - view on LGTM.com

fixed alerts:

• 1 for Mismatching new/free or malloc/delete

[lgtm-com[bot]]

This pull request fixes 1 alert when merging 7cf2be974db15799fb8c0cd3f8b9f808623dd84f into f06439f77e50974e427023f77a459843e46ac682 - view on LGTM.com

fixed alerts:

• 1 for Mismatching new/free or malloc/delete

[ni4]

Notably, the final state of the codebase is exactly identical to current master, perhaps we could do without duplicating the history? It's visible that you've carefully considered each commit, but I'd prefer to not have to deal with parallel lineages and such large PRs.

It's how we did it before and described in release-workflow.adoc. If you have better ideas/experience on the release workflows - feel free to discuss. We need to have separate release and master branches, as at some point we may need to make a minor update(say, quick security fix), which would not include whole set of changes from the master.

[andrey-utkin]

Well, that was my entire proposal. If the current state of master branch is what we are happy with for the release, then I suggest we tag that state of master branch as 0.16.1, and don't busy ourselves applying the procedure which is more appropriate for when we must actually diverge in code. I don't see any risk in this case, but it skips a lot of mental load, and makes simple tooling (such as git show-branch) work better on the codebase.

[antonsviridenko]

It would be nice if fix for https://github.com/rnpgp/rnp/issues/1894 is also included in this release, otherwise looks fine

[ni4]

Well, that was my entire proposal. If the current state of master branch is what we are happy with for the release, then I suggest we tag that state of master branch as 0.16.1, and don't busy ourselves applying the procedure which is more appropriate for when we must actually diverge in code.

@andrey-utkin We had a case when we needed to diverge in code (pick only few security related commits from the master for a new release), and, as I noted, must be prepared to such case in the future. Given that there is no any problem on cherry-picking commits from the master into the release branch using the proper tooling, why should we change to the less-flexible approach?

[andrey-utkin]

why should we change to the less-flexible approach?

I didn't mean that we have to forbid the backporting as a possibility for release making. What I'm saying is that in this case, we could have done a much simpler action without upsetting anyone. I do mean that the release-workflow.adoc has low credibility to me.

Given that there is no any problem on cherry-picking commits from the master into the release branch using the proper tooling

I disagree here. The problems are wasting (current and future) developers time to make sense of unnecessarily complicated commits history.

[ni4]

It would be nice if fix for #1894 is also included in this release, otherwise looks fine

Please see reply in the original issue. If it's okay to ship - feel free to approve.

[ronaldtse]

I don't think the discussion of the release workflow should be performed here.

@antonsviridenko if you are okay with the response on https://github.com/rnpgp/rnp/issues/1894, please feel free to approve the release. Thanks!

[ronaldtse]

Thank you guys!