When all revisions are of equal quality, the one that gets the upgrade further along is is indeed the better choice. But in the case where I have a [2, 3, 4] revision but realise the direct 2 -> 4 handling is buggy and can’t sensibly be fixed in that new version of the software and so I need to split into [2, 3] and [3, 4], the one with the greatest epoch is no longer the best choice. It’s also strange that releasing the new [2, 3] revision would appear to work but actually have no effect on anything.
Unreleasing would be one way to solve the problem, but that’s not currently a concept that exists, partly because it’s not clear how that should interact with channel history, particularly when it comes to gatings and closed channels.
Well, it needs to exist no matter what we agree on here. People need to be able to pull out things that were released by mistake for other reasons. My undertanding was this was already possible. If it’s not, let’s please put that on the agenda.
Unreleasing hasn’t been interesting so far; only tip of a channel is significant today, so you can just re-release the revision that you want clients to have. But the ability to unrelease becomes important once epochs cause us to start considering non-tip revisions, so we’ll put it on the list to discuss at the next sprint.
We’ll proceed with implementing option 2 (greatest epoch wins) for now. There are still some unresolved issues around what happens when a channel is closed, but they’re not blockers for the next stages of the server-side implementation.
Even without epochs that’s already not true. There are reasons why people can artificially lock a revision into availability as long as it has been released publicly and not unreleased. For example, the proxy can tune revisions based on that public history, and refresh-control can also be used to do the same.
