search

freedomofpress / securedrop-builder

Packaging logic for building SecureDrop-related Debian packages
GNU General Public License v3.0
7 stars 11 forks source link

Switch securedrop-keyring to use calendar-based versioning #446

Open legoktm opened 1 year ago

legoktm commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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.