I use the version format major.minor.release.build. I currently have version 2020.1.3.54 deployed in production. When someone checks in the next change they need to increment the release number, IE 2020.1.4.1. How can I force that in Octopus Deploy?
A couple of general FYIs in terms of how Octopus functions. A release number, 2020.1.3.54, can only exist once per project. If I wanted to create the exact same release (for testing) I would have to name it something like 2020.1.3.54-Testing. In addition, out of the box, you can’t overwrite packages by default. It is possible, but you have to supply the additional command prompt --force.
Now that is out of the way, onto the specific question. We don’t have that exact functionality. But what you can do is write a script that leverages the API to check if that version, 2020.1.3, has already been deployed to production.
Your script would first get the project information: [BaseURL]/api/[SpaceID]/projects?partialName=[Project Name]
That will kick back project(s) where you can pull the ID. Once you have the ID you can hit the releases endpoint: [BaseUrl]/api/[SpaceId]/projects/[ProjectId]/releases?searchByVersion=2020.1.3&skip=0&take=10000.
Then you can loop through each of the releases to find out if it went to Production: [BaseUrl]/api/[SpaceId]/releases/[ReleaseId]/progression
Where that script runs is up to you. What you could do is run it on the build server fail the build. Or you could run it in Octopus and cause a manual intervention. Perhaps you needed to deploy another build of 2020.1.3 for an emergency bug fix.
I did something similar where if a major version was changed then it required a manual intervention, see more here.