Denoting Latest "Stable" Releases in Change Notes?

Legacy Execution
1

Given some mishaps introduced in 3.8.x, we have decided to take a more conservative approach to upgrading Octopus Server.

The current rationale is -1m old from the most current release. See: https://octopus.com/downloads/previous

While navigating the change logs – https://octopus.com/downloads/compare?from=3.14.15926&to=3.12.8 – it’s not very clear when to pick “newer” releases because a previous release introduced serious or breaking changes.

Would it be feasible for Octopus Deploy to denote “Stable” releases (e.g. 3.14.10) as they’ve backed in the wild for some time and based on customer feedback?

We do have a suite of integration and test projects to try to spot functionality regressions – so we’re talking more about server-side issues / unexpected changes. Breaking Changes seems to generally be used for intentional behavior changes.

2

Hi Jai,

Sorry about the delay to get back to you!

So we’ve had a discussion about this within the team and currently we think that the best strategy would be to go with the latest previous major.minor version (eg if we’ve released 3.16 then 3.15.latest should be regarded as the most stable.

We have also had a discussion about how we could denote a release as stable without a too negative impact on our processes.

I hope that helps somewhat!

Thank you and best regards,
Henrik

3

I appreciate it! That helps a lot. I hope you can find a solution that is not too impactful on your current process. I do love the way your release notes are setup.

Until downstream/upstream servers are finalized/baked in, we are affecting 20+ teams with a single Octopus Server upgrade over 3 HA nodes (soon 4).