Release Changes

usability
(Michael Christensen) #1

I am currently testing out the Release Changes feature in v2019.6.7 LTS on-prem.

We have a setup similar to the one pictured in


where every build produces a release, which is auto-deployed to a DEV environment.
However, for all projects, including ones where metadata has been pushed for its packages and JIRA integration / release note generation based on included commits works perfectly, every deployment to subsequent environment (similar to the “1.0.3” deployment in the blog post) will list the single release being deployed, even if multiple releases have been made to DEV in between.

A specific example:
I have a project where releases have been deployed like this:

If I press deploy on release 4.0.21-master-7120239 to DEVTEST i expect Release Changes to list releases 4.0.20-master-8728983 and 4.0.19-master-0722176 as well. Similarly, if I press deploy to AcceptTest, I expect 4.0.20-master-8728983 to be included.
However, both deployment previews list only 4.0.21-master-7120239 in Release Changes:


Am I missing something to make this scenario work?

(Shannon Lewis) #5

Hi Michael,

Thanks for getting in touch. What you’re hitting there is by design. The deployments roll up the details from all versions that are not pre-releases. A pre-release will only ever include its own change.

The reasoning is that the pre-releases are “working versions”. Imagine you had 2 development branches going, you might have 4.0.21-featureA and 4.0.21-featureB both being built. Within each you’re likely to have a number of builds, e.g. for each time you push. So you might have 4.0.21-featureA0001 and 4.0.21-featureB0001. They are both prereleases of 4.0.21 to SemVer, and both could be deployed to the same environment, but are they accumulations of each other? They aren’t.

Channels can be used to isolate the work streams, but we couldn’t rely on everybody having channels configured as pseudo branches, so the safest option was for prereleases to only include changes for the exact version being deployed.

What tooling are you using to generate the version numbers? If you are able to use SemVer metadata rather than prerelease (i.e. 4.0.21+master-7120239 rather than 4.0.21-master-7120239) then you’ll get the accumulation working correctly. Using the - as a separator is a thing we commonly see, as it’s impact and behavior with regard to SemVer isn’t always apparent.

I hope that helps clarify, if not or if you have any further questions please let me know.

Regards
Shannon

1 Like
(Michael Christensen) #6

Hi Shannon

That makes sense, and in our particular case, switching to non-pre-release versions is not a problem. And I can confirm it works exactly as you describe.
You might want to call this out explicitly in the articles describing the feature and/or update the documentation (https://octopus.com/docs/packaging-applications/create-packages/versioning), which currently states

When it comes to application versioning, we suggest the pre-release tag (the bit after the - ) can be used however works best for you. For example, you could build version 1.5.2-rc of your application and configure a Channel to promote packages like *-rc to Staging and eventually Production.

I have a vague recollection of similar guidance in some earlier Octopus blog post which, combined with issues with build metadata in package/build/Octopus versions at the time, lead us to use prerelease versions for Octopus releases originally.

Anyways, thanks for helping me out :slight_smile:

Regards
Michael

(Shannon Lewis) #7

No problems, glad I could help.

I think that’s a good idea too, regarding calling this out more clearly in the documentation, I’m working on that right now.

Shannon