design a versioning (and updating) scheme

[jku]

We have multiple separate components at play:

• signers installed from this repo
• github actions in this repo
• workflows from playground-template (not necessarily up-to-date) in the "customer" repository, invoking the the github actions

We should figure out what is easiest way to maintain dev velocity while allowing repositories to run stable versions

• workflows should likely use pinned actions
• but we should document how to keep the actions updated -- maybe we can just do releases of repository-playgreound actions and advice to use dependabot

[jku]

How to keep signing tool version compatible with repository version

• Start making signing tool releases to pypi
• Signing tool cannot currently tell if it is compatible with the repository software version
• We could add some sort of signing tool version marker in the metadata. Then signing tool could refuse to run if it's not compatible with the metadata it receives
• Required signing tool version could be in root metadata (since that's the first one we parse) but that would potentially require root signing to update software versions... so putting the required signing tool version in timestamp would be technically easier

How to keep repository software up-to-date without forcing everyone to live on bleeding edge

• We should tag releases of the repository actions / software
• We should document the releases. Most importantly document all changes required in the workflows: The workflows within the user projects do not get auto-updated so we need to make it clear when changes are required on version update
• the workflows (playground-template) should pin release hashes by default
• dependabot should be recommended

Potential problems

1. release version confusion Signing tools and repository live in the same repository. I'm not sure which is less problematic: both having the same version numbering or having two separate versioning schemes inside one repo. I think I lean towards separate versions, and e.g. "v1.2.3" tag being the action version and "signer-v3.2.1" being the signing tool version (The actions version needs to be unprefixed to make sure dependabot can handle it)

2. workflow drift We likely can't automate updates to the workflow files... but that means over time they may become more and more different from the ones in playground-template possibly leading to obscure bugs.

proposed task order

1. start tagging action releases and making signing tool releases to pypi
2. pin hashes in workflows
3. maybe add signing tool version marker in metadata