Cadence Releases

[demirkayaender]

Hey Cadence Community! Here are some updates about our release strategy. We have been talking to some members from the community about this to get their feedback and this seems to be the most appropriate one. Please let me know if you have any feedback.

Background: At Uber we want to switch to continuous, semi-continuous (every 2 weeks) releases to always run the freshest code and reduce the diff in-between releases. This will also significantly reduce the time to investigate any issues and increase the reliability of the overall system.

However, when we sought feedback from major external users, they didn’t like this idea and wanted to have a release cadence of ~3 months. Below were the reasons:

• Biggest issue was to avoid operational burden of having to validate/certify and upgrade frequently.
• They also wanted to be included in the release process where we announce a new release is coming and if anybody wanted to include their changes.
• However, they were still interested in still seeing what’s internally running if they needed to apply fixes to their deployments etc.

So to address this, and given version string format is major.minor.patch:

• We think we should increment patch version every time we make an internal release so externally the build we run would be known. But since they are patch releases, this won’t necessarily require an upgrade.
• We will increment the minor version when we make the quarterly release so this could be clear from outside too.
• ~1 month before the quarterly release we will announce that we are planning to make a release at the end of the month (e.g. announce in the first week of September and release at the end of September) so this could give enough time to community to finalize the features and make it in the release.
  • Quarterly release announcement won’t block the patch releases and we can still have several of them between the announcement and the release.
• As always, we will still document the diff between every patch release and every minor version release (from patch to patch and from minor to minor version).

Note that since we already started 1.1.x; that release would be exempt from this process.

This will hopefully bring more structure and clarify to our releases and would make open source community more informed and less confused.

[slater-ben]

Hi Ender - this looks like a really good proposal, thanks!

It may be worth providing a little bit more detail on what happens between the code freeze and the actual release for the quarterly releases. How would this normally be expected to take? Would we make a release candidate/beta available for testing prior to declaring a quarterly release stable and GA?

Also, probably can be resolved later if needed, but what is the projects policy on backporting fixes? Lets say a major bug or critical CVE is discovered 2 months after a quarterly release (ie 3 or 4 incremental feature releases would have occurred). Do we provide something that is just the quarterly release + the fix for that major bug or do we purely roll forward so people have to pick up the incremental feature releases to get the bug fix? If we're going to go back (which is probably preferable from my POV), then how far back (probably only 1 or 2 quarters I would imagine)?