Use Case

The Node team recently established a process to backport patch releases to existing minor branches. This requires careful construction of release tooling for the target branch and backporting the tooling because the release tooling is only maintained on the main branch.

Creating new release tooling and backporting it causes friction in the release process. Additionally, because our release tooling is only maintained on `main`, updates to dependencies that is used by release tooling might require additional changes to backport (ex: adopting release-please v4 requires backporting the major version upgrade changes to old branches).

We should investigate ways of decoupling all our release configuration from main, so that backporting changes is simpler.

User Experience

n/a

Dependencies

n/a

Risks/Unknowns

n/a

Acceptance Criteria

Implementation Requirements

• Investigate the following questions:
  • Is it possible to remove release configuration from main so that the tooling can be maintained separately? (moving it into a shared GHA, perhaps?)
    • If so, do the benefits outweigh the drawbacks?
  • Can we automatically generate backport release configuration when we release minors, removing the need to backport release configuration?
• Write up results somewhere that the team can reference and discuss the results with the team.

Testing Requirements

n/a

Documentation Requirements

n/a

Follow Up Requirements

• review the outcome of the spike with the team
• file tickets for any follow up work or changes we want to make as an outcome of this spike