Hi
Consider the following. For the next release of the application, you have made some changes the process and variables. Before the new version of the application is deployed you need to deploy a hotfix. The hotfix will require the old process and variables. It would be nice if the process and variables was versioned and when creating a new release in Octopus one could choose either the latest version or any previous version of process and/or variables.
Versioning the process and variables would also better document the changes in the deployment prosess, ref. Configuration Management in ITIL
Thanks for getting in touch! What you are suggesting is a really good idea! You want to maintain a stable release process for v1.x of your application, whilst developing and deploying v2.x of your application which may require different variables and processes.
Prior to Octopus 3.2 our customers would achieve this by cloning the project, keeping one as the stable project for hot fixes, and iterating on the copy for the new version of the project. This is problematic because it forces you to maintain two projects in parallel.
In Octopus 3.2 we shipped the feature we call Channels which allows you to evolve your deployment design over time in a very nice and safe way, without the need for cloning. We describe this process in detail in the Channels Walkthrough for Octopus 3.2.