Skip to content

Commit

Permalink
docs: document module breaking changes process.
Browse files Browse the repository at this point in the history
This adds a section outlining the process to follow
going forward with regards to making breaking changes
to modules.
  • Loading branch information
dnldd committed Sep 11, 2019
1 parent 2b0f3ce commit 8e575dc
Showing 1 changed file with 26 additions and 0 deletions.
26 changes: 26 additions & 0 deletions docs/code_contribution_guidelines.md
Original file line number Diff line number Diff line change
Expand Up @@ -7,6 +7,7 @@
4.2. [Testing](#Testing)<br />
4.3. [Code Documentation and Commenting](#CodeDocumentation)<br />
4.4. [Model Git Commit Messages](#ModelGitCommitMessages)<br />
4.5. [Handling Module Breaking Changes](#HandlingModuleBreakingChanges)<br />
5. [Code Approval Process](#CodeApproval)<br />
5.1 [Code Review](#CodeReview)<br />
5.2 [Rework Code (if needed)](#CodeRework)<br />
Expand Down Expand Up @@ -269,6 +270,31 @@ a good thing.
wrap our plain text emails such that there’s room for a few levels of nested
reply indicators without overflow in an 80 column terminal.
<a name="HandlingModuleBreakingChanges" />
### 4.5 Handling Module Breaking Changes
Pull requests that introduce breaking changes to modules must ensure dependent
modules on the change are updated to referrence newly bumped module versions.
The purpose of this is to improve the release process by handling version
updates with the pull request that introduces it instead of waiting until
release.
The request submitter should ensure the following steps are covered whenever a
new breaking change to a module's API is introduced:
- Bump the major version in the `go.mod` of the affected module if not already
done since the last release tag. Note that v1 modules are stablilized even
without a release, breaking changes to such modules will require a major
version bump as well.
- Add a replacement to the `go.mod` in the main module if not already done since
the last release tag.
- Update all imports in the repo to use the new major version as necessary.
- Make necessary modifications to allow all other modules to use the new
version in the same commit.
- Repeat the process for any other modules the require a new major as a result
of consuming the new major(s).
<a name="CodeApproval" />
### 5. Code Approval Process
Expand Down

0 comments on commit 8e575dc

Please sign in to comment.