Rather than allways taking the "latest" version of a package, can we scope the step to within a particular version range
When you create a release, Octopus default to picking up the latest version of the available packages.
We have multiple forks of our packages, and we need to be able to restrict a package step so that it is limited to a particular version range of the package, for example:-
If we have a major version 1 of a package on a step,
If we later create a fork and do work on a major version 2,
We do not want the next octopus release to pick up major version 2 - we want to limit the scope of the step so that it can not go above major version 2.
NuGet itself supports this concept when specifying package dependencies using notation like:
1.0 = 1.0 ≤ x
(,1.0] = x ≤ 1.0
(,1.0) = x < 1.0
[1.0] = x == 1.0
(1.0) = invalid
(1.0,) = 1.0 < x
(1.0,2.0) = 1.0 < x < 2.0
[1.0,2.0] = 1.0 ≤ x ≤ 2.0
empty = latest version.
If we could specify this on the nuget package step it would great.
At the moment, the way we have to currently handle this is have a seperate nuget feed per major version, which complicates our build and release process and adds a fair bit of overhead.
This ability is available via the Channels feature as provided in Octopus Deploy 3.2 (http://docs.octopusdeploy.com/display/OD/Channels).
Channels can specify version rules that define what packages are included in that release.
Paul Wilcox commented
Is there any reason why this is specific to 'Channels' and can't be used in a normal/default pipeline? - We try and avoid channels as we want/enforce a single 'Route-To-Live' but there are times where we want to enforce a particular package version to be used (e.g. we want to force a lower version than the most recent available).
Is this functionality available in 'Multi-Tenanted Deployments'? - i.e. specify particular versions/ranges per 'Tenant'?
We'd also want to be able to do this in 'Step Templates'...
Darrell Tunnell commented
Hi Andrew, yes I believe so too, I had actually allready commented on that blog post too that effect - should make life a lot easier :)
Andrew McClenaghan commented
I think the new branching rfc would cover most of this. http://octopusdeploy.com/blog/rfc-branching
We use the built-in NuGet repository and when deploying projects we normally have 2-3 applications deployed per project.
We would like to be able to specify wildcards on the NuGet package versions so we can group them and then get the latest version in a group per application.
This way we can have multiples releases that are grouped per branch in our deployment.
Continuous Dev Builds:
WebService App - Version Wildcard: 0.0.1.*
Web App - Version Wildcard: 0.0.1.*
Feature 1 Branch Build:
WebService App - Version Wildcard: 0.1.*
Web App - Version Wildcard: 0.1.*
Feature 2 Branch Build:
WebService App - Version Wildcard: 0.2.*
Web App - Version Wildcard: 0.2.*
Darrell Tunnell commented
sorry small typo in my example I meant to write: "we want to limit the scope of the step so that it can not go above major version 1."