patch releases

patch-releases.md

We're releasing! Why?

1. We felt like it - we knew this was coming
   1. sick new features => major/minor
      • We've gotten pretty good at this 👍 usually we just hit shipit on the main pipeline and profit. But we also need to create some branches on a few repos and a patch pipeline in most cases.
      • Usually some engineer is pushing for this (I want to see my pet feature in the hands of users and bask in their admiration)
   2. fixing something embarrassing => patch latest minor
      • If we were diligent about on the main pipeline and profit. But we also need to create some branches on a few repos and a patch pipeline in most cases.
      • Usually the engineer who was pushing for their pet feature now wants to save face by getting a fix out quickly
2. We had to - we're interrupted by the need
   1. pressure for a fix/feature for a customer => patch the PivNet version they are using
      • usually we're doing some kind of fix or feature work like crazy because we just realized we're gonna lose millions of dollars
      • Somebody usually owns this and has a customer/PA/other leader breathing down their neck.
      • Question if we provide a patch to one version, should we apply it to all relevant/possible PivNet versions as well as the latest minor?
   2. a CVE => patch all the PivNet versions
      1. the CVE is in the Concourse codebase
         • usually this is actual work we have to think carefully about, it takes some time/prioritization and there's somebody lovingly ensuring the patched versions get shipped.
         • Question should we also be patching the latest minor? Probable Answer YES
      2. the CVE is in one of our dependencies
         • usually we can just write a quick release note and re-release if the patching pipelines have been doing their job.
         • Usually nobody really "owns" this. we have a support contract, but do customers even do the patch upgrades for CVEs!? 😬
         • Question should we also be patching the latest minor? Probable Answer YES

Process changes

1. obviously let's nominate a release anchor for every release event, who will make sure that the important code gets written, the release notes get written, and the various shipping jobs are run
2. should we make issues to track our progress on CVEs, or is it wrong to announce them before shipping a fix?
3. how far left can we shift these processes? can bugs that need to be backported have this noted in their describing issue? maybe those issues don't close until we have PRs for each branch that needs the fix.
4. let's agree on a backporting process - the usual shenanigans re. rebase/merge/squash