Octopus.Date and Octopus.Time - Breaking Change

We have a project that is a “Master Orchestration” project that deploys other projects using the API. Releases get created manually for this, and previously we have set the default version number to be


Though I recognize that is not a valid SemVer due to potential leading zeroes, it was a convenient way to tell when this release was created.

Due to the changes of requiring valid SemVer on release numbers, our releases now cannot be automatically created using this format. It throws an (incorrect) error stating that you need at least two parts in your version. The error is not descriptive, and should inform the user it is due to leading zeroes.

Worse, you can have a leading zero in the main version number, but not in the pre-release tag. Neither are valid SemVer numbers, and if you are going to enforce this I feel it should be done in both spots. Exmaples:

2017.02.10-11.57 is valid

2017.02.10-09.57 is not

Finally, even if consistency is added in the SemVer enforcement, and the error is cleaned up, this is a breaking change. The Octopus project settings show examples for version numbers. I feel it would be ideal to have #{Octopus.Date.} and #{Octopus.Time.} trim leading zeroes so that they can once again be used for versioning, or at least introduce new variables (so as to not include another breaking change). Currently I am unable to use these for version numbers as their own number, as the month, day, hour, and minute may all include leading zeroes.

Hi Chris,

Thanks for the feedback.

We want to allow the flexibility to enter a version number that makes sense to you so we don’t stricty enforce SemVer. I think disallowing leading zeros in the pre-release tag was an oversight, I’ve created an issue to allow it: https://github.com/OctopusDeploy/Issues/issues/3166

In the meantime you could add a prefix to your pre-release tag. Eg: