I have two questions related to how Octopus sees new version and such.
We are looking into having Teamcity create our versions with more semantics. An example would be “app version-branch-commit-teamcityBuildNumber” style. For example “Calculator 1.4.2-dev-4fae6a0-345”. The idea is also to have Octopus switch on these using channels. For example so that DEV branch is deployed to one environment while FEATURE001 is deployed to another. Are we looking into any kind of pain when using this kind of versioning with Octopus for deployments? Anything that we should avoid or notice before we just try it?
Currently our versions is just “Calculator 1.4.2-b354”. But we would like to reset those build numbers from Teamcity (here "354) or move the build to new definitions which would also reset the build number. What happens in Octopus if we do that? Would it be business as usual if it perhaps at some point sees the same version again? It would not deploy right? How to deal with this?
Thanks for getting in touch! With 3.4 we were able to upgrade both our SemVer support and NuGet to 3, so these version numbers will be supported at that point. Unfortunately until then you will get errors with invalid version string.
There are ‘pain points’ when it comes to changing your versioning schemes for an existing project. As releases are ordered by alphanumeric, if you start with a lower ordered version the wrong packages will be selected and a few other issues start to arise.
Generally the only way forward is to make a new project via cloning or delete the old releases.
Let me know if I can expand on any of this.
We shall be awaiting 3.4. with much anticipation (versioning, multitenancy, lots of great improvements)
Thanks for getting back.
Just need some clarification, you said “As releases are ordered by alphanumeric”. This made me wonder how far your naming requirements extend.
For example. would “1.4.2-dev-aaaaa-346” be a valid successor to “1.4.2-dev-bbbbb-345”?
Next you say " delete the old releases". How to do that? Do I need to use Octo.exe for this?
Currently in this case
1.4.2-dev-aaaaa-346 would be considered higher than
1.4.2-dev-bbbbb-345 but I may have to check if the SemVer libraries allow for better breakdown of the tag now that it has upgraded.
Octo.exe is the easiest way to delete releases in bulk. But you would only have to delete anything that would get in the way of the new naming conventions.
I had a chat to the dev. We are hoping that the NuGet updates will adhere directly with the SemVer rules, but even those http://semver.org/#spec-item-11 (see precidence) would not work for your versioning strategy.
If your build number is more important I would have to suggest using it before your commit. We will try to address any incompatibilities when 3.4 is out if any are found.