|
| 1 | +# Releases |
| 2 | + |
| 3 | +## Versioning |
| 4 | + |
| 5 | +etclabscore/core-geth uses [Semantic Versioning](https://semver.org). The API definition that would demand increments to the major version is basically nil; |
| 6 | +it can be expected that a major version bump would be accompanied by an entirely new repository and name. |
| 7 | + |
| 8 | +Tagged versions use the suffix `-stable` and untagged versions (ie everything else) uses the `-unstable` suffix. |
| 9 | + |
| 10 | +You can find some historical discussions on versioning at the following links. |
| 11 | +- https://github.com/etclabscore/core-geth/pull/29#issuecomment-588977383 |
| 12 | +- https://github.com/etclabscore/multi-geth-fork/issues/153 |
| 13 | +- https://github.com/etclabscore/core-geth/pull/30#issuecomment-591979271 |
| 14 | +- https://github.com/etclabscore/core-geth/issues/83 |
| 15 | + |
| 16 | + |
| 17 | +## Developers: How to make a release |
| 18 | + |
| 19 | +- [ ] Decide what the new version should be. In this example, __`v1.11.16[-stable]`__ will be used. |
| 20 | +- [ ] `git checkout master` |
| 21 | +- [ ] `make lint` and `make test` are passing on master. :white_check_mark: |
| 22 | + > This is important because the artifacts to be included with the release will be generated |
| 23 | + by the CI workflows. If linting or tests fail, the workflows will be interrupted |
| 24 | + and artifacts will not be generated. |
| 25 | +- [ ] `git checkout release/v1.11.16` |
| 26 | +- [ ] Edit `params/version.go` making the necessary changes to version information. (To `-stable` version.) _Gotcha:_ make sure this passes linting, too. |
| 27 | +- [ ] `git commit -S -s -m "bump version from v1.11.16-unstable to v1.11.16-stable"` |
| 28 | +- [ ] `git tag -S -a v1.11.16` |
| 29 | +- [ ] `git push etclabscore v1.11.16` |
| 30 | + > Push the tag to the remote. I like to do it this way because it triggers the tagged version on CI before the branch/PR version, |
| 31 | + expediting artifact delivery. |
| 32 | +- [ ] Edit `params/version.go` making the necessary changes to version information. (To `-unstable` version.) |
| 33 | +- [ ] `git commit -S -s -m "bump version from v1.11.16-stable to v1.11.17-unstable"` |
| 34 | +- [ ] `git push etclabscore` |
| 35 | + > Push the branch. This will get PR'd, eg. https://github.com/etclabscore/core-geth/pull/197 |
| 36 | +- [ ] Draft a new release, following the existing patterns for naming and notes. https://github.com/etclabscore/core-geth/releases/new |
| 37 | + > - Define the tag the release should be associated with (eg `v1.11.16`). |
| 38 | + > - Linux, OSX, and Windows artifacts will be uploaded automatically to this release draft by the CI jobs. There should be CI-generated 16 assets total. |
| 39 | + > - __NOTE__ If the release is not drafted manually, it will be automatically drafted by the CI. |
| 40 | +- [ ] Await a complete set of uploaded artifacts. If artifacts fail to upload due to issue with the CI jobs, review |
| 41 | + those jobs to determine if their failure(s) is OK, restarting them if so. |
| 42 | +- [ ] Once artifacts have been uploaded and the release draft reviewed by one other person for the following, it's time to publish! |
| 43 | + + proofreading |
| 44 | + + artifact fingerprint verification |
| 45 | + + notes content approval |
| 46 | +- [ ] Once the release is published, merge the associated PR bumping versions. |
0 commit comments