Release 22.8.20.1

[exarkun]

This widens the allowed range of Tahoe-LAFS versions and bumps the version number. If it passes CI then we can tag it as a release. This will make integration with newer Tahoe-LAFS possible without pulling in any of the other recent development work on ZKAPAuthorizer (which is good because it has some known bugs).

[codecov[bot]]

Codecov Report

Merging #443 (9dd628b) into main (63c05fb) will decrease coverage by 0.02%. The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main     #443      +/-   ##
==========================================
- Coverage   96.37%   96.34%   -0.03%     
==========================================
  Files          63       63              
  Lines        7526     7526              
  Branches     1012     1012              
==========================================
- Hits         7253     7251       -2     
- Misses        203      204       +1     
- Partials       70       71       +1     

Impacted Files	Coverage Δ
src/_zkapauthorizer/__init__.py	100.00% <100.00%> (ø)
...rc/_zkapauthorizer/tests/test_lease_maintenance.py	94.55% <0.00%> (-1.99%)	:arrow_down:
src/_zkapauthorizer/tests/test_storage_protocol.py	97.99% <0.00%> (+0.80%)	:arrow_up:

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

[meejah]

so is codecov revealing heisen-coverage, or just confused yet again?

[exarkun]

so is codecov revealing heisen-coverage, or just confused yet again?

It could be heisen-coverage. The way Hypothesis is set up right now does not guarantee the exact same codepaths will be covered on each CI run. The plan for this is to make the PR-triggered run use a CI profile that's deterministic and run a, say, nightly CI job that's randomized. This way PRs don't get the random noise but Hypothesis still has a chance to discover new problems for us.

[exarkun]

I had to change the version number from v2022.8.20.1 to v2022.8.21 because the release automation doesn't trigger for 4 component version numbers. :( (And I didn't want to mess with the release automation in this PR)

[meejah]

I don't see a problem with the 3-number one (but I guess you're trying to encode that it's a "spot release" on .8.20 ...?)

[exarkun]

I don't see a problem with the 3-number one (but I guess you're trying to encode that it's a "spot release" on .8.20 ...?)

Yea, that. The biggest annoyance is just another 40 minute CI run, I think.

[meejah]

I guess "calver" is somewhat vague; I've used YY.MM.## (where ## just increments) because the most common reason I've had for "another minor release" is that I screwed something up so it's often on the same day ;)

From calver.org's "case studies", looks pretty split on whether the second number is "month" or "a number that goes up".

I suppose to support a use-case like this, it would make sense for the second number to just be "something that increases" (so then "normally" you'd increase that number, but for patch/spot/whatever releases, the right-most number would increase). Or, use 4 numbers .. but that seems far less common IME.