Skip to content

Version bump patch decision tree

Jump to bottom
Kevin Chang edited this page Sep 3, 2021 · 8 revisions

Factors influencing a version bump

For issues that are uncovered during the QE phase of the version bump, the next course of action can vary depending on the nature, size and scale of the issue. These issues generally fall into two categories:

⚠️ If either of these types of issues is significant enough to consider delaying the version bump for any reason, consult the section below on version bump delays before beginning any patch or revert process. Reach out to the UXD leads for any assistance on next steps.

Breaking changes and functional problems

If the issue is a breaking change, we'll need to determine the scale of its impact:

Cosmetic issues

For cosmetic issues, check with the QE assigned to the domain on the level of impact. Even if the issue can be corrected with a patch, it may be favorable to wait until the version bump PR has merged before creating a patch. Holding off on a patch will require fewer passes for the QE team, as adding a patch to the version bump may need QE to re-test the entire PR.

If a cosmetic patch affects functionality indirectly or otherwise, we follow the process for breaking changes and functional problems.

Version bump delays

Ultimately, the decision to delay a version bump falls upon the version bump assignee. If you have any doubts on whether to delay, feel free to reach out to the UXD leads and/or the UXD group at large for advice. Notify the QE team as soon as possible when a delay will occur, and when they might expect the next or revised version bump for review.

Delay considerations

Take these factors into account before making a final decision on whether to delay a version bump:

  • While we value our metrics in tracking version bumps timing, the numbers for on-time delivery are not a primary concern. We should always err on the side of safety and stability rather than trying to get a version bump "out the door".
  • Blocking work in kajabi-products. If this is the case, clarify with any affected cross-functional teams on how their work may be impacted, and if a delay is acceptable.
  • Upcoming weekends and holidays. Generally, we avoid deploying any new or updated code before a weekend or holiday. Doing so helps to minimize regressions from occurring outside of regular work hours. We recommend at least one full day of buffer time between a version bump and a weekend or holiday. This may result in a delayed version bump being pushed until the following week.

Version bump patch process

  1. In kajabi-products, create a new branch based off of the Sage version bump PR's branch
  2. Apply the fix(es) and confirm that the issue is corrected when testing locally
  3. Create a new PR for your patch branch, making sure that the base has been set to the Sage version bump's branch
  4. Follow the normal process for readying a PR for review, assigning appropriate reviewers
  5. Once approved, merge the patch branch into the Sage version bump PR
  6. Update the Sage version bump PR description to indicate a patch has been applied (this should already appear in the github timeline)
  7. Notify QE that the patch has been merged, and that the version bump PR is once again ready for testing

Version bump revert process

  1. Notify the UXD group and QE in slack that a revert will be necessary
  2. Determine a timeline for a follow-up version bump, and notify both UXD and QE to be prepared. This may be the next day, making sure all related factors have been weighed.
  3. If there are no objections from either group within a reasonable amount of time (30-45 min), close the kajabi-products version bump PR
  4. Follow the steps in the sage-lib revert process to revert the branch in Sage and start a new version bump

Thanks for using Sage!

Welcome

Conventions

Processes and Reference

Clone this wiki locally