Switch securedrop-keyring to use calendar-based versioning

[legoktm]

https://calver.org/

During the last keyring release, we noted that the standard major.minor.patch doesn't really make sense here.

Instead we could something like <year>.<month>.<patch> (the actual day doesn't really matter and not really feasible to know ahead of time).

If we decide to switch for the upcoming release, then the new keyring version would be 2023.06.1+bullseye ("06" to imply it's a month but just "1" to not imply that it's a date)

[rocodes]

Sorry I didn't clue into this when I was looking at #448 and ramping up for this release. This is fine with me, but will probably be a 'next time' type thing.

Do you (or anyone) have opinions about whether or not we'd want to switch the other sdw components for consistency? I don't have strong opinions either way. But I think the fewer exceptions to rules we have, the happier we will be.

[cfm]

Thanks for suggesting this, @legoktm! I'm in favor.

On Mon, Jun 05, 2023 at 12:42:34PM -0700, rocodes wrote: Do you (or anyone) have opinions about whether or not we'd want to switch the other sdw components for consistency? I don't have strong opinions either way. But I think the fewer exceptions to rules we have, the happier we will be.

My initial (predictable? :-) reaction is that we (for any value of "we") could answer this question quickly enough by listing all our repositories in column A of a spreadsheet and their ideal versioning schemes in column B, with semantic versioning as the default. I suspect there will be very few exceptions, but it would be interesting to see (a) if there are any patterns and (b) whether the exceptions are all good candidates for calendar versioning.