|
1 | 1 | # Orbit Release Process |
2 | 2 |
|
3 | 3 | ## Full Release |
| 4 | + |
4 | 5 | 1. Create a **doc-refresh** branch. Add the logs of changes under |
5 | 6 | [changelog](https://github.com/uber/orbit/blob/dev/docs/changelog.rst). |
6 | 7 | The logs can be reused later for drafting release notes. |
7 | 8 | Rerun notebooks under **docs/tutorails** for defined readthedocs triggered job. |
8 | 9 | 2. Submit a PR to dev branch for any changes of any documentation. |
9 | 10 | 3. After the approval and merge from previous PR, create a release branch from `dev` |
10 | 11 | - e.g. `release-v1.0.15` |
11 | | -4. Update the version number in `orbit/__init__.py`. This version number will be propagated to `docs/conf.py`, `setup.cfg`, and `setup.py`. |
| 12 | +4. Update the version number in `pyproject.toml`. This version number will be propagated to `docs/conf.py`, `setup.cfg`, and `setup.py`. |
12 | 13 | 5. Commit changes |
13 | 14 | 6. Test PyPI deployment locally by running [Optional] |
14 | 15 | - `python3 -m build` |
15 | 16 | - `python3 -m twine check dist/*` |
16 | 17 | - `python3 -m twine upload --repository testpypi dist/*` |
17 | | - - Verify the package on https://test.pypi.org/project/orbit-ml/ |
| 18 | + - Verify the package on <https://test.pypi.org/project/orbit-ml/> |
18 | 19 |
|
19 | 20 | > **Legacy (deprecated):** `python3 setup.py sdist bdist_wheel` |
20 | 21 | 7. If necessary, additional PRs may be merged to the release branch directly, but this should be for bug fixes only. |
|
29 | 30 | - `git push origin dev` |
30 | 31 |
|
31 | 32 | here option `--no-ff` is important to have same commit ids between `master` and `dev`; `git rebase` instead of `git merge` is to avoid the additional merge commit. |
32 | | -10. Draft a new release: https://github.com/uber/orbit/releases/new |
| 33 | +10. Draft a new release: <https://github.com/uber/orbit/releases/new> |
33 | 34 | - Select the `master` as the target branch |
34 | 35 | - Use version number for both the tag and title e.g. `v1.0.15` |
35 | 36 | - Add a bulleted list of changes in the description; this can be similar to change logs from step 1. |
36 | 37 | 11. Click `Publish Release` once all changes are finalized and description is updated |
37 | | -12. All the documentation should be refreshed and can be found in https://orbit-ml.readthedocs.io/en/stable/ |
38 | | - |
| 38 | +12. All the documentation should be refreshed and can be found in <https://orbit-ml.readthedocs.io/en/stable/> |
39 | 39 |
|
40 | 40 | ## Quick Release |
| 41 | + |
41 | 42 | Sometimes we just want to release a patch, and no subsequent commits are needed on the release branch. |
42 | 43 | In this case, we can avoid creating the branch and create a release directly from dev. |
43 | 44 |
|
44 | 45 | 1. From `dev`, update the version number in `orbit/__init__.py`. |
45 | 46 | 2. Commit changes |
46 | 47 | 3. Merge to `master` |
47 | | -4. Draft a new release: https://github.com/uber/orbit/releases/new |
| 48 | +4. Draft a new release: <https://github.com/uber/orbit/releases/new> |
48 | 49 | - Select the master branch as the target branch |
49 | 50 | - Use version number for both the tag and title |
50 | 51 | - Add a bulleted list of changes in the description as well as |
51 | 52 | [changelog](https://github.com/uber/orbit/blob/dev/docs/changelog.rst). |
52 | 53 |
|
53 | | - |
54 | 54 | ## Hotfix |
| 55 | + |
55 | 56 | Sometimes we may need to address a bug fix directly from master after a release, but `dev` may have moved on with new commits. |
56 | 57 |
|
57 | 58 | 1. Create a hotfix branch from master and update the version number |
58 | 59 | 2. Make fix |
59 | 60 | 3. Merge changes into `master` |
60 | | -4. Draft a new release: https://github.com/uber/orbit/releases/new |
| 61 | +4. Draft a new release: <https://github.com/uber/orbit/releases/new> |
61 | 62 | - Select the master branch as the target branch |
62 | 63 | - Use version number for both the tag and title |
63 | 64 | - Add a bulleted list of changes in the description as well as |
|
0 commit comments