You can use the same channel with the following caveats:
Nuggets built from two branches obviously must have different (non-colliding) versions. I add the suffix 'dev' to the package built from the dev branch (for example, 1.2.3.4-dev) and leave the branch โstableโ open.
You have to be explicit when you create the release, because by default Octopus will get the available version of nuget with the highest version, and it may not be the release you want (stable supposedly lags dev). Select the version of the package you need (and set the deployment version accordingly). If you are creating a release through TeamCity, make sure that you use the --packageVersion argument and set the release number.
Since the above only works if there is only one package in the release, the deployment process (unfortunately) should create one monolithic nuget, or you will get version mismatches.
The advantage of this kind of arrangement, of course, is that with a pinch you can push your dev construct to QA (or Prod) if necessary.
All this suggests that both branches are built as the same package , of course. You can create different packages between the dev and stable branches (but I donโt think I recommend this because of duplication of the entire Octopus configuration).
Update: obviously you can use Octo.exe to specify different version numbers in different packages - see https://github.com/OctopusDeploy/Octopus-Tools .
source share