Rooba
/
lightning
mirror of https://github.com/Lightning-AI/lightning.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

how to make release

Jirka Borovec 2020-11-13 15:59:31 +01:00
parent 969c2e5551
commit c4b47d7625
1 changed files with 46 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

53
Releasing.md

@ -17,13 +17,50 @@ release/1.0.x: \--b1---b2--------b3---------b4---b5---b6
release/1.1.x: \--b8---b9
```
## Release process
## Make a release
1. check that all tests are passing and all badges are fine - green
2. double check the docs (even we have docs build among check it is better to check `latest` [build](https://pytorch-lightning.readthedocs.io/en/latest/))
3. set the release version in `__init__`
4. check that you have included all substantial changes in [CHANGELOG.md](https://github.com/PyTorchLightning/pytorch-lightning/blob/master/CHANGELOG.md) together with release number and date (and remove redundant blank lines in list)
5. _[optional]_ create `sdist` locally and check if the attached package decoration (it is generated from our Readme) is correct and all images are shown
This preparing content for a particular release depends on what kind of release we are making - feature/bugfix. Bellow, we shortly talk about what shall be prepared for making a smooth release.
### Pre-release requirements/assumptions
As described in the Release strategy above we are merging all PR to the default/master branch.
We need to make sure that during PR review all points from both checklists ([before submitting](https://github.com/PyTorchLightning/pytorch-lightning/blob/master/.github/PULL_REQUEST_TEMPLATE.md#before-submitting) and [PR review](https://github.com/PyTorchLightning/pytorch-lightning/blob/master/.github/PULL_REQUEST_TEMPLATE.md#pr-review)) are addressed, in particular for release purposes we rely on filling milestones and setting `bug/fix` label.
At this moment we do not use any automatic merging so the final merge to master is performed by a PL core contributor and at this time he has to check that the PR has assigned a release version according to milestone and label resolution - meaning if PR is indicated as bugfix aka `1.0.x` milestone and has `bug/fix` label it shall be added to open release, e.g. `1.0.7`.
### Feature release
This is simple as we are releasing from the master which is also PR target so all commits there shall be fine all the time.
The only difficulty is (a) updating changelog with missing notes as it is after a quite long time and (b) filtering changelog by notes/commits which were already released as part of any previous bugfix release.
_Sanity check, open actual changelog and most notes shall be in **Added** or **Changed** eventually **Deprecated/Removed**._
### Bugfix release
In principle, this is cherry-picking from default/master branch all bugfixes related to the last feature release as illustrated in the scheme above. To do you use any Git IDE by your preference and open the ZenHub release report.
1. Double check that all [merged PRs in last week](https://github.com/PyTorchLightning/pytorch-lightning/pulls?q=is%3Apr+is%3Aclosed+sort%3Aupdated-desc) (we have a weekly cycle for bugfix releasing) have set a milestone, label, and release. If some is missing or you are not sure that it is correct aka PR title says it is a feature but it is set labeled as a bug or set in bugfix milestone ask @edenlightning or @tchaton.
2. Close actual release and show [its report](https://app.zenhub.com/workspaces/lightning-all-5f9840e8ac6aae0010d13f8f/reports/release?release=5fabbf10ad9b1d519282c067) which you will use for cherry-picking.
3. Create a new branch e.g. `release/1.0.7` for this lets say `1.0.7` release from base `release/1.0.x`
4. Find the oldest commit in the released report from the last release, in this demo case from `1.0.6`
5. Start cherry-picking one by one all commits presented in the release report - if needed solve collision and add missing change notes
6. Verify that all picked commits have change note (if needed, e.g. docs edit does not need be mentioned in changelog)
7. Push `release/1.0.7` to the origin (GitHub) and wait till all build passes
8. Merge this temp branch to bugfix branch `release/1.0.x` without squashing, all build shall be taken over as the last commit os the same from you pushed to `release/1.0.7`
9. if not done yet, increase version in `__init__.py` and continue to Publish release
Friendly suggestion: push time to time you breach to the origin (Github) which will trigger a full build and you may discover eventual issue sooner than at the end of your cherry-picking, good commit count is 2-3. This is recommended especially you have to solve some collision while this cherry-picking...
_Sanity check, open actual changelog, and section **Added** shall be almost empty and most notes shall be in **Fixed** section._
FYI, we are actually working on some semi-automatic workflow that would take the last commit, check whether it is a candidate to ongoing bugfix release and create a secondary PR to this release branch.
## Publish a Release
1. Check that all tests are passing and all badges are fine - green
2. Double-check the docs (even we have docs build among check it is better to check `latest` [build](https://pytorch-lightning.readthedocs.io/en/latest/))
3. Set the release version in `__init__`
4. Check that you have included all substantial changes in [CHANGELOG.md](https://github.com/PyTorchLightning/pytorch-lightning/blob/master/CHANGELOG.md) together with release number and date (and remove redundant blank lines in list)
5. _[optional]_ Create `sdist` locally and check if the attached package decoration (it is generated from our Readme) is correct and all images are shown
6. Finally, [create the release](https://github.com/PyTorchLightning/pytorch-lightning/releases/new) which is automatically pushed to `pip`
7. Open [Read-The-Docs](https://readthedocs.org/projects/pytorch-lightning/) and build release docs for this new release
@ -37,4 +74,6 @@ The release notes shall be composed of the following three sections:
### After the release
- do any promo as needed...
- add me section to CHANGELOG and keep in mind that already created PRs are adding their changes to past release which shall be moved to the new unreleased section...
- add me section to CHANGELOG and keep in mind that already created PRs are adding their changes to past release which shall be moved to the new unreleased section...
Disclaimer, this is an internal guideline document so if you have some more question or suggestion, please talk to @Borda or @edenlightning