Thanks for putting these in place, @facundobatista. Very useful for the conversation.
Here we go:
Scenario 1 – Looks good!
Scenario 2 – Looks good!
Scenario 3 – The 3.4 case looks bogus. The fact r12 (e1, #15) is released late just means it becomes the most recent snap on epoch 1. If this snap is installed it should still go to r10 (e2*, #11) and then to r14 (e3*, #16), and finally r17 (e3, #17). The underlying logic is that epochs never go backwards. After we release e3, that’s the most recent epoch and the one that will remain at the tip until something more recent comes up. That said, we do allow older epochs to be released, and they become the tip of their own epoch (most recent e1 in the example). In other words, the epoch order (0, 1*, 1, 2*, 2, 3*, 3) is preserved no matter what the release order is. If we didn’t do that, we’d be completely unable to ever release a new 1* after anything higher was released, as it would completely break the sequence.
Scenario 4 – Case 4.7 is wrong, but that’s probably just a typo in the table. It asks for 8 and should get 8. In fact, case 4.10 is just a double of 4.7 with the result corrected. Remaining cases look right, but there’s one more tricky case that needs to be accounted for and is not in the table: if updating from 6 to 8 to 6 to 5, the first two operations should work, and the last must fail because it went “through” a non-double-starred revision which means the compatibility promises may have been broken and the backwards compliance is gone. This logic is mostly in snapd itself rather than the store.
Scenario 5 –
5.4 is bogus because a double-starred epoch allows the revert to happen, but it doesn’t change the fact epoch 0 is lower than epoch 1**. In this sense, a double-starred revision works exactly the same as if this was a single-starred 1* epoch, and thus incompatible with epoch 0. The rule of thumb is that we never go backwards to previous epochs automatically. Update: Your suggestion actually sounds better. Please see details below.
Rest looks good.
One note about sequencing and revisions. While the separation of sequence vs. revision in Scenario 3 is useful to explicitly acknowledge the fact that what matters is the sequence of releases rather than the number of the revision, it also made the scenario pretty hard to track, and other scenarios actually imply that the revision is sequentially released. I’d suggest thinking about revisions as sequentially released just for facilitating the conversations around it, but explicitly mentioning that revision numbers are just identifiers and not used for ordering. All of these scenarios might have the revision numbers randomized and they’d still be valid.