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
#{Octopus.Date.Year}.#{Octopus.Date.Month}.#{Octopus.Date.Day}-#{Octopus.Time.Hour}.#{Octopus.Time.Minute}
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.