I just hit something unexpected with the octo.exe create-release command.
In order to get separate life cycles for release branches vs dev branches I started using channels for one of our projects just the other day. I almost copied the command from an old project, but I changed --packageversion to --version (and added --channel) since I (subconsciously) always had intended both the package version and the release version to be the same. But while, in my process at least, --packageversion both selected the package version and set the release version the opposite was not true and lead to some unexpected results that were not immediately obvious.
While I can see the reason for having two separate options in some odd corner cases I wonder if there is a good reason for --packageversion implying --version but not the other way around?
Oh, forgot to note what happened:
I asked for --version=1.7.3.9 so OD said: Ok, he wants to create release 1.7.3.9, let’s surprise him by using the package with version 1.7.4.2, latest version is better, right?
The param --packageversion should not enforce both Package and Release version. It should only enforce the version of the package that’s gonna be used in that release. Unless your project versioning strategy ( Projects -> [Project name] -> Settings -> Versioning Strategy ) is set to Use the version number from an included package, in which case the following should happen:
You want Octopus to use version 1.0.0 for the package used in the step named “DeployWebApp” so you pass the param --packageversion=DeployWebApp:1.0.0 to Octo.exe
Octopus checks the release versioning strategy and says “Ok, here it says I should use the version of the package used in the step ‘deployWebApp’ as release version. So I’m gonna create the release 1.0.0 and use the package version 1.0.0 as well”
Only in that scenario Octopus should use the value in --packageversion to also set the release version.
(a bit of a long delay here, but the world interferes)
Thank you, I had forgotten (or suppressed) that it worked that way with package version controlling release version through that option even though I had set up the project myself.
My real confusion came from doing it the other way around by only specifying --version to octo.exe create-release and having a package of a later version automatically used in that release, but I assume that that is the expected behaviour? If no package version is specified, the latest available package is used?
With hindsight I might wonder if it would be a good idea if the default was that release version and package versions where linked and having them differ would be the exception.
having a package of a later version automatically used in that release, but I assume that that is the expected behaviour? If no package version is specified, the latest available package is used?
That’s the expected behavior, correct.
Like I explained in my previous reply, we offer the option of enforcing the Release version to be the same as the package version. But not the other way around.
The logic behind this is that in your application lifecycle you basically do these 3 things:
(1) Build -> (2) Pack -> (3) Deploy.
The recommended practice is to have the previous step defining the version of the step that comes next. So the build defines the version of the package, and the package version defines the version of the deployed release. This means that version set in step (1) ultimately defines the versioning of all the other steps.
The Octopus release number is not as important as the version of the package that you are deploying to your servers. That’s why we offer the option to set the release based on the package version, and not the other way around.
Hope that helps you understand a bit our logic behind this behavior
