The AssemblyVersion attribute is used by OctoPack (v2 only) to ensure version uniqueness each time a package is uploaded to the OctopusDeploy server. Two problems with this, first problem is that the version number although unique (i.e. 1.0.5555.76432) is not SemVer compatible and separately the version bears little resemblance to the AssemblyInformationVersion (i.e. 1.0.0).
My preferred solution is that we use the AssemblyInformationalVersion for the NuGet packages and somehow increment this number at build time (i.e. 1.0.0-beta[build increment]) so that the version reported by a .NET compiled DLL matches the version of the NuGet package and both are SemVer compatible. I have seen several version incrementers online but many either appear to be very old or they are dependent on XAML templates which we don’t use. What does everyone else do to achieve this as we can’t be the only ones to have this requirement with such a common setup?
Linked to the above query, if we manage to implement a solution where the AssemblyInformationalVersion contains SemVer tags such as “1.0.0-beta1” isn’t there a fundamental conflict with release promotion here? I was under the impression that a release should be promoted from Development -> Test -> Production without a rebuild if all testing has passed, but if we version the Assembly and NuGet package as “1.0.0-beta1” then this means that a release with “beta” in the name has been promoted to Production when really we want it to be 1.0.0. The only way to work around this of course is to change the version in the .NET assembly and then re-build and re-promote the release but this is inherently risky as other source code changes could have been made since the last build. Am I missing something here?
Thanks so much for responding I feared no one was going to reply!
I’ve taken a quick look at GitVersion and it looks promising I just need to find some time today or tomorrow to try it out. FYI, we use TFVC not Git source control but there doesn’t appear to be any dependency on Git source control for this version incrementer to work.
Any additional information you could provide on the post would be useful (not only for me but for anyone else with the same queries). I’d also be interested in an answer to my release promotion and version query below:
“Linked to the above query, if we manage to implement a solution where the AssemblyInformationalVersion contains SemVer tags such as “1.0.0-beta1” isn’t there a fundamental conflict with release promotion here? I was under the impression that a release should be promoted from Development -> Test -> Production without a rebuild if all testing has passed, but if we version the Assembly and NuGet package as “1.0.0-beta1” then this means that a release with “beta” in the name has been promoted to Production when really we want it to be 1.0.0. The only way to work around this of course is to change the version in the .NET assembly and then re-build and re-promote the release but this is inherently risky as other source code changes could have been made since the last build. Am I missing something here?”
Kind regards,
Ian Clarkson
Development Manager | Cash Management Solutions
GitVersion relies heavily on Git, sorry. One option available to you is to move your TFVC repository to a Git repository on the same TFS server.
Regarding your other query, our recommendation is to build your packages once and promote through your environments. This works great when your team is only working on a single branch/version at the time (consider Centralized Workflow using TFVC or GitHubFlow). This approach starts to fall apart when you need to support multiple versions concurrently, which is where branching strategies like GitFlow emerged.
At Octopus we use GitFlow because we are concurrently:
Supporting 3.2.0, 3.2.1, 3.2.2…
Working on general 3.3 work in the develop branch 3.3.0-unstable0001, 3.3.0-unstable0002…
Working on Feature Branches 3.3.0-multitenancy0001…
We wrote a custom PowerShell script for TeamCity that would inspect the branch being built and calculate a sensible version number for it. Now we’re using GitVersion which has proven to be much more reliable at calculating a deterministic version based on the Commit and branch history.
When we are preparing to ship Octopus, we will Tag the latest successful Commit with the version number we want, today will be 3.2.4, and we rebuild that set of packages, and eventually deploy them.
As you mentioned, there is an inherent risk to rebuilding, but it is up to you to decide based on merit, how much risk you are willing to accept.
Thanks again for taking the time to answer my question and providing insight on how Octopus version their own releases, this is very interesting to me as my team is still relatively new to this sort of thing.
We currently work on a single branch at a time (i.e. Master, 3.2.0, 3.3.0 etc.) as we only have a few developers but as the team grows I can definitely see us switching to a feature branch model so I will consider the merits of moving to a Git repository so we can leverage the full capabilities of GitVersion and GitFlow.
Kind regards,
Ian Clarkson
Development Manager | Cash Management Solutions
