|
| 1 | +# Release |
| 2 | + |
| 3 | +This file describes the process for publishing a new version of the gem as a GitHub release. |
| 4 | + |
| 5 | +Releases are managed through the [GitHub Releases](https://github.com/ideacrew/event_source/releases) page. |
| 6 | + |
| 7 | +Release names follow the [Semantic Versioning](https://semver.org/) standard. |
| 8 | + |
| 9 | +Follow the steps below to package and release a new version of the gem. |
| 10 | + |
| 11 | +## Major/Minor release |
| 12 | +### Prepare the release |
| 13 | +1. Checkout the main branch and pull the latest changes. |
| 14 | +2. Create and checkout a branch - avoid naming the branch solely after proposed release number - something like 'rm12313453_v1.0.0._update_gemspec' might be ideal. |
| 15 | +3. Update the version number in the `lib/<project>/version.rb` file. Note the [correct format](https://guides.rubygems.org/specification-reference/#version); only digits and dots are allowed. Do not include a `v` prefix. |
| 16 | +4. Update the `Gemfile.lock` file: |
| 17 | + - `bundle update --patch --conservative event_source` will generally reduce dependency bumps. Typically, other effects in the lockfile beyond the gem itself being bumped should be discarded. |
| 18 | + - See bundler documentation for detailed information on how this [command](https://bundler.io/v2.5/man/bundle-update.1.html) behaves. |
| 19 | +5. Commit the changes with a message like `bump version to v1.0.0`. |
| 20 | +6. Push the branch and raise a pull request against the main branch. The pull request title should follow the format: `bump version to v1.0.0`. Be sure to label the pull request with the `version-bump` label. |
| 21 | + |
| 22 | +### Publishing the Release |
| 23 | +1. Once the pull request is approved and merged, checkout the main branch and pull the latest changes. |
| 24 | +2. Create a new release branch in the pattern of `1.0.x-release`. |
| 25 | + - Note: `x` is literal, to aid reuse of same branch for minor bugfixes. |
| 26 | +3. Create a new annotated tag with the version number, e.g., `git tag -as v1.0.0 -m "v1.0.0"`. |
| 27 | + - IMPORTANT: make sure the tag abides by the format `vX.Y.Z` where `X`, `Y`, and `Z` are integers. It is important that the tag name has a different format than any branch name to avoid confusion with Bundler. |
| 28 | +4. Push the tag to the remote repository, e.g., `git push origin refs/tags/v1.0.0`. |
| 29 | + - Avoid `git push --tags`, to not accidentally push random assorted local tags. |
| 30 | +5. GitHub Actions will automatically create a new release on the [GitHub Releases](https://github.com/ideacrew/event_source/releases) page with release notes. Confirm that the release was successfully published there and that all intended commits are included in the release. |
| 31 | + |
| 32 | +## Patch/Bugfix release |
| 33 | +### Prepare the release |
| 34 | + |
| 35 | +1. Fix bug in the main branch, via normal PR process. |
| 36 | +2. Create a temp branch off any live release branch that has the bug - pick a name that won't conflict with another branch or tag, as with Major/Minor step 2. |
| 37 | + - Using a branch, which is then PR’d, ensures traceability and inclusion of an item in the generated release notes. |
| 38 | +3. Cherry-pick the fix commits to the temp branch. |
| 39 | +4. Update the gem `version.rb` file and `Gemfile.lock` as in Major/Minor release steps 3 and 4. |
| 40 | +5. `git push` the temp branch. |
| 41 | +6. Issue a PR to merge to the release branch. |
| 42 | +7. You will need to do this for each branch that has the bug. |
| 43 | + |
| 44 | +### Publishing the Release |
| 45 | +1. Once the pull request is approved and merged, checkout the release branch and pull the latest changes. |
| 46 | +2. Create a new annotated tag with the version number, at the point of the release branch with the fix, e.g., `git tag -as v1.0.1 -m "v1.0.1"`. |
| 47 | +3. Push the tag to the remote repository, e.g., `git push origin refs/tags/v1.0.1`. |
| 48 | + - Again, better to avoid `git push --tags`. |
| 49 | +4. Github Actions will create the release and pull in the fix PR's to the changelog. |
| 50 | + |
| 51 | +## Using a Tagged Release in Another Project |
| 52 | +To use the new release in another project, update the project's `Gemfile` to reference the release's tag, e.g., `gem 'event_source', git: 'https://github.com/ideacrew/event_source.git', tag: 'v1.0.0'`. |
| 53 | + |
| 54 | +## Git Process diagram |
| 55 | + |
0 commit comments