- Change "IS NOT" to lowercase (not an RFC 2119 keyword)
- Change "you can update" to "you MAY update" in section 3.9
- Capitalize "should" to "SHOULD" in sections 8.7 and 9.6
- Remove ".x" suffix naming variant from long-term release branches
Add support for release pull requests as an optional workflow. When
usingrelease PRs, the release tag SHOULD be placed on the resulting
merge commitrather than the version bump commit itself.
Changes:
- Add new item 7.5 defining release pull requests
- Update item 7.4 to reference the release PR exception
- Update item 8.6 to allow tagging merge commits for release branch PRs
- Renumber items 7.5-7.9 to 7.6-7.10
Move Git Best Practices from section 10 to section 5, placing it after
Pull Requests and before Versioning. This positions best practices for
commits, rebasing, and force-pushing earlier in the document where they
are more relevant to daily development work.
- Renumber sections 5-9 to 6-10
- Update cross-reference in section 7.2 (section 5.1 → 6.1)
- Normalize "Long-term" to "Long-Term" for consistency
Expand FAQ section to provide clear strategies for managing monorepos
using Common-Flow. Cover key considerations such as branch management,
versioning approaches, and maintaining consistency across packages.
Replace the dead Atlassian blog link with a newer and more comprehensive
explanation of `git push --force-with-lease`, providing clearer context
for developers about this important git workflow practice.
Update guidelines for commit messages to recommend Conventional
Commits specification. Clarify best practices for version bumps,
breaking changes, and semantic versioning alignment. Emphasize
benefits of structured commit messages for changelog generation
and automated version determination.
Allow for pulling in changes from the source branch either via
rabasing or merging, instead of only allowing rebasing. Rebasing is
still recommended however.
