Description
Since a incompatible spec version update seems to get more interest (see #2040), we should start with actually designing how spec version numbers are going to work... Who is responsible for setting the version and what tools exist to help there?
As an example, lets say that TUF spec decides that succinct delegations are an incompatible spec addition -- this is a reasonable decision as adding succinct delegations to a targets metadata makes it invalid for older clients. Let's say, this is spec version 2.0.0.
Assume python-tuf supports spec 2.0.0. Now repositories are going to have many reasonable choices. At least these exist:
- start using 2.0.0 in all new metadata files (but keep old ones as is even when the are resigned). This is what happens by default with current python-tuf: this leads to bugs as soon as
- succinct delegations are added to existing metadata
- new metadata is added that old clients should be able to access
- start using 2.0.0 in all metadata files whenever they get re-signed. Issues appear when:
- any metadata that old clients should be able to access is resigned
- start using 2.0.0 in all metadata that contain succinct delegations but legacy version in all others, even newly created metadata -- this allows old clients to keep accessing any metadata that doesn't contain succinct delegations
The last one is arguably most useful but also quite tricky to implement, at least in python-tuf (likely a lot easier in the repository itself): it might be possible to write methods that scans the metadata structure and decides "what is the lowest spec version that this structure supports": this method could be used by the repository when it's updating expiry,version,etc metadata content to also set spec_version at that time.