georgizk
commented
7 years ago this is sort of fixed by api redesign - always need to upversion release when changing from draft to released status. still might need some attention, though - ideally should never edit a release once it's been put in released state
The below applies for releases of the same project and chapter.
It should not be possible to reuse the same version once a release goes from "released" to "draft" and back to "released" status. e.g. if a release of version 1 was ever in "released" status and then changed back to "draft" status, it should not be possible to use version 1 again. That is because when a release is in draft status it is possible to change the pages; without this restriction, you could end up with "version 1" releases in the wild that have different contents, which defeats the purpose of having a version. This should extend even to releases that got deleted. e.g. if a release of version 1 was in "released" state and got deleted, it should not be possible to create another release that uses version 1.
A simplifying approach could be to simply never allow for a release to be changed once it's put in "released" status - not even delete. This would get broken by a project deletion, but you could argue that even that should not be allowed.