While in dev, my package versions are SemVer prerelease versions. (ie 1.0.3-build.62)
But once I move past the revisions of dev, I need to drop the prerelease part and just have 1.0.3 for my package version.
How can I get Octopus deploy to update the package version based on the environment being deployed to?
Thanks for getting in touch!
It sounds like our Channels feature might be what you are after. Channels allow you to dynamically select packages at release creation time based on version rules and tags. The release is created for the defined Channel and the desired package will be selected based on rules/tags configured in the Channel.
Does this look like what you are after?
If you have any questions at all on this, please don’t hesitate to let me know.
Channels look interesting. But if I I am still stuck with needing to use build numbers in dev, but not wanting a prerelease version number after I promote from Dev to Test (and eventually Prod).
The only way around this (that I can see) is to either:
- Somehow get Octopus Deploy to use the non-prerelease package version number when promoting a release from Dev to Test (and from Test to Prod).
- Or starting a new release with the non-prerelease version number. This is hard because Octopus has no way to trigger this besides manually creating a release (which would be too complicated for everyday use with the feed being bound to (requiring manual version number entry), using tenants and channels.
I am confused how everyone else is using build numbers in dev and not promoting prerelease packages to Test and Prod. SemVer seems to have not been fully thought through (though I am sure it was).
Thanks for following up! I’ll jump in for Daniel as he’s offline for the rest of the week.
While there is no way to vary the package version per deployment (these are hardcoded into the release snapshot to ensure it’s the same throughout the whole lifecycle progression), I’m also thinking channels might be the best option.
Channels allow you to have different releases follow different lifecycle progressions. i.e. you’d have a lifecycle that only goes to Dev, and set a channel to use that lifecycle that only allows packages with the pre-release tag. Then have a second lifecycle that just goes from Test to Prod, and a separate channel using that, that only allows non-pre-release packages.
Then when you specify the channel in the create release step in your build process, the version rules will give you control over which package version should be selected for the release that is being created in that channel.
I’m hoping that might help address your second point and help avoid manually creating the releases via the UI? Let me know what you think!
This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.