Release Checklist TEMPLATE

[reactive-firewall]

Release Checklist:

ℹ️ This is the checklist that I try to go through for every single release. If you're wondering why it takes so long for me to complete stable releases, this is why.

---

General

• Is this change useful to me, or something that I think will benefit others greatly?

• Check for overlap with other PRs.

  Those PRs are . . . << include a list >>.
  OR
  This will introduce . . . << description of what is changed only by this PR's set of changes >>.

  • For Example:

    • Closes << link to issue >>
    • Contributes to << link to issue >>

• Think carefully about the long-term implications of the change.
  • How will it affect existing projects that are dependent on this?

    Breaking changes include . . . << include a list of impacts to dependents >>
    OR
    This <<PR type, ie version|update|patch>> . . . << previous version this can safely upgrade from >>.

  • How will it affect my projects? If this is complicated, do I really want to maintain it forever?

    • Opens << issue references >>

  • Is there any way it could be implemented as a separate package, for better modularity and flexibility?
    • yes

      . . . << plan for how >>

      • include the following advisory at the bottom of your plan.

      🚧 CAUTION: 🏗️ This is still experimental. ⛔ DO NOT MERGE AS IS. 🙅🏻

    • No

---

Check the Code

• If it does too much, ask for it to be broken up into smaller PRs.

• For Example:

  This is too monolithic, please consider breaking this PR into parts.

  These numerous changes are disjoint, please reorganize into separate, smaller PRs.

• Does it pass make test-style (flake8, etc.)?

  These changes follow the current project style conventions as tested by make test-style

  See project Makefile
  OR

  • include the following advisory until it is fixed.

  🚧 CAUTION: 🏗️ This is still experimental. 🔧 Fix in progress. ⛔ DO NOT MERGE AS IS.

• Is it consistent?

  This change follows current project style conventions as tested by make test-style

  See project Makefile
  OR

  • Comment on the PR describing style convention violations.
  • include the following advisory until it is fixed.

  🚧 CAUTION: 🏗️ This is still experimental. 🔧 Fix in progress. ⛔ DO NOT MERGE AS IS.

• Review the changes carefully, line by line. Make sure you understand every single part of every line. Learn whatever you do not know yet.

🗒️ Take the time to get things right. PRs almost always require additional improvements to meet the bar for quality. Be very strict about quality. This usually takes several commits on top of the original PR.

---

Check the Tests

• Does it have tests for all the changes? If not:
  • Comment on the PR "Can you please add tests for this code to tests/test_blah.py"
    OR
  • Write the tests yourself.
• Do the tests pass for all of the CI tests? If not:
  • Comment on the PR requesting a fix for the regression in CI.
    OR
  • Fix them yourself

AND
* include the following advisory until it is fixed.
> 🚧 CAUTION: 🏗️ This is still experimental. 🔧 Fix in progress. ⛔ DO NOT MERGE AS IS.

---

Check the Docs

• Does it have docs? If not:

  • Comment on the PR "Can you please add docs for this feature to the wiki"
    OR
  • Write the docs yourself.

• If any new functions/classes are added, do they contain docstrings?

---

Credit the Authors

• Add name and URL to README.md for security fixes.
• Thank them for their hard work.
• Close Issues

---

Release (optional)

Decide whether the changes in master make sense as a major, minor, or patch release.
Look at the clock. If you're tired, release later when you have time to deal with release problems.

• Merge the PR branch. This will close the PR's issue.
• Close any duplicate or related issues that can now be closed. Write thoughtful comments explaining how the issues were resolved.

[reactive-firewall]

Helpful context:

• https://github.com/reactive-firewall/python-repo/blob/v1.1.4/.github/PULL_REQUEST_TEMPLATE.md
• https://dev.to/opensauced/how-to-create-a-good-pull-request-template-and-why-you-should-add-gifs-4i0l
• https://docs.github.com/en/issues/tracking-your-work-with-issues/creating-an-issue
• https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/creating-diagrams
• https://mermaid.js.org/intro/

Status Quo workflow:

• Releases are tracked in stable
• Staging is done in master then released into stable
• development is done on feature branches then squash merged into master.

%%{init: { 'logLevel': 'debug', 'theme': 'base', 'gitGraph': {'mainBranchName': "stable"}} }%%
gitGraph BT:
       commit id: "init"
       commit id: "Ancient History" tag: "v1.1.(n-2)"
       commit id: "History" tag: "v1.1.(n-1)"
       branch master
       branch feature-branch-xyz
       branch feature-branch-abc
       checkout feature-branch-abc
       commit id: "add a"
       checkout feature-branch-xyz
       commit id: "add x"
       checkout feature-branch-abc
       commit id: "add b"
       commit id: "add c"
       checkout feature-branch-xyz
       commit id: "add y and z"
       checkout master
       merge feature-branch-abc id:"PR abc"
       merge feature-branch-xyz id:"PR xyz"
       checkout stable
       merge master id: "RELEASE PR" tag: "v1.1.n"
       commit id: "Future" tag: "v1.1.(n+1)"
       commit id: "Far Future" tag: "v1.1.(n+2)"

Loading

This requires two types of PRs:

• Normal PRs (usually into master)
• Release PRs (into stable)

[reactive-firewall]

Historically this whole issue started with:

          fix the FIXME here 🤦🏻

Originally posted by @reactive-firewall in #34 (comment)

[reactive-firewall]

Companion PR/MR Review Guide is found here:

• CEP-4