I’ve split this discussion out of the previous thread since this is a slightly orthogonal conversation and interesting on its own.
So, yes, those two scenarios you presented sound great, but let me outline a more comprehensive description of what seems to be a good place for us to be in:
- Any channel may be open or closed
- Any channel may have a fallback setting defined, which means once closed it causes the client to observe the tip of a different channel as its own
- When a channel does not have the fallback setting defined it behaves the same as if no snaps were ever published there
- The client never changes the channel without an explicit administrator action doing so
- As a matter of policy (rather than implementation), there is no fallback across different tracks, because the whole point of tracks is to give the user a chance to opt into a well defined and disjoint sequence of revisions
- Tracks may be hidden, which imply clients can still use the channels in them, but should refrain from doing so since these tracks are going away; this does not affect the fallback behavior described above, and is merely a way to drive a track out of use without disrupting service
How does that sound?