Repository navigation
document release checklist #6986
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 1 commit
fc54ea5
821299c
93b25bf
b153c84
98a8bef
34f0949
7639be6
3ff2b4a
d1faf06
b7c6bbf
f3a8401
077c896
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,97 @@ | ||
| Numba Release Checklist Templates | ||
| ================================== | ||
|
|
||
| The goal of the Numba release process -- from a birds eye perspective -- is to | ||
| publish source and binary artifacts that correspond to the given version | ||
|
esc marked this conversation as resolved.
Resolved
|
||
| number. This usually involves a sequence of individual tasks that must be | ||
| performed in the correct order and with diligence. Numba and llvmlite are | ||
| commonly released in lockstep since there is usually a one-to-one mapping | ||
| between a Numba version and a corresponding llvmlite version. | ||
|
|
||
| This section contains various notes and templates that can be used to create a | ||
| Numba release checklist on the Numba Github issue tracker. This is the aid for | ||
|
esc marked this conversation as resolved.
Resolved
|
||
| the maintainers during the release process and helps to ensure that all tasks | ||
| are completed in the correct order and that no tasks are accidentally omitted. | ||
|
|
||
| Historically, the release checklists were copied from one release to the next. | ||
| While this worked OKish for many years, often times tasks were lost during | ||
| repeated copy and paste. As a result this document was created to keep track of | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is the history needed?
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. not sure, maybe not, it was mostly documenting my personal motivation, I can remove it if just adds overhead.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm not sure it's necessary, a good reason for this process is presented in the previous paragraph. I'd rather spend effort keeping documentation such as this accurate with respect to changes/updates, if you feel differently am happy to discuss.
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. sure, no need for that perspective here. |
||
| all potential tasks. All templates within this document are written in Github | ||
| Markdown and can be copied verbatim to a GitHub issue to create a release | ||
| checklist. | ||
|
|
||
| If new or additional items do appear during release, please do remember to add | ||
| them to the checklist templates. Note also, that the release process itself is | ||
| always a work in progress. This means, some of the information here may be | ||
| outdated. If you detect this, please do remember to submit a pull-request to | ||
| update this document. | ||
|
esc marked this conversation as resolved.
Resolved
|
||
|
|
||
|
|
||
| Minor Version Release Candidates | ||
| -------------------------------- | ||
|
|
||
| This is for first minor version release candidates. I.e. the first release of | ||
| every series. It is special, because during this release, the release branch | ||
| will have to be created. Release candidate indexing begins at 0. | ||
|
|
||
| .. code-block:: | ||
|
|
||
| ## Numba X.Y.Z | ||
|
|
||
| * [ ] merge to master: | ||
| - [ ] "remaining Pull-Requests from milestone" | ||
| * [ ] merge change log changes | ||
| - [ ] "PR with changelog entries | ||
| * [ ] Create X.Y release branch | ||
| * [ ] pin llvmlite to `>=0.A.0rc1,<0.A+1.0` | ||
| * [ ] annotated tag X.Y.Zrc0 on release branch | ||
| * [ ] build and upload conda packages on buildfarm (check "upload") | ||
| * [ ] build wheels (`$PYTHON_VERSIONS`) on the buildfarm | ||
| * [ ] upload wheels and sdist to PyPI (upload from `ci_artifacts`) | ||
| * [ ] verify packages uploaded to Anaconda Cloud and move to `numba/label/main` | ||
| * [ ] verify wheels for all platforms arrived on PyPi | ||
| * [ ] verify ReadTheDocs build | ||
| * [ ] clean up `ci_artifacts` | ||
| * [ ] review, merge and check execution of release notebook | ||
| * [ ] send RC announcement email / post announcement to discourse group | ||
| * [ ] post link to Twitter | ||
| * [ ] post link to python-announce-list@python.org | ||
|
|
||
| ### Post Release: | ||
|
|
||
| * [ ] tag X.Y+1.0dev0 to start new development cycle on `master` | ||
| * [ ] update llvmlite dependency spec to match next version via PR to `master` | ||
| * [ ] update release checklist template | ||
| * [ ] close milestone (and then close this release issue) | ||
|
|
||
| Second Releases Candidates, Final Releases and Patch Releases | ||
| ------------------------------------------------------------- | ||
|
esc marked this conversation as resolved.
Resolved
|
||
|
|
||
| A patch release usually involves a series of cherry-picks, so the recipe is | ||
| slightly different. | ||
|
esc marked this conversation as resolved.
Resolved
|
||
|
|
||
| .. code-block:: | ||
|
|
||
| ## numba X.Y.Z | ||
|
|
||
| * [ ] cherry-pick items from the X.Y.Z milestone into a PR | ||
| * [ ] merge change log modifications and cherry-picks to X.Y release branch | ||
| * [ ] https://github.com/numba/numba/pull/XXXX | ||
| * [ ] annotated tag X.Y.Z on release branch (no `v` prefix) | ||
| * [ ] build and upload conda packages on buildfarm (check "upload") | ||
| * [ ] build wheels (`$PYTHON_VERSIONS`) on the buildfarm | ||
| * [ ] upload wheels and sdist to PyPI (upload from `ci_artifacts`) | ||
| * [ ] verify packages uploaded to Anaconda Cloud and move to `numba/label/main` | ||
| * [ ] verify wheels for all platforms arrived on PyPi | ||
| * [ ] verify ReadTheDocs build | ||
| * [ ] clean up `ci_artifacts` | ||
| * [ ] send RC/FINAL announcement email / post announcement to discourse group | ||
| * [ ] post link to Twitter | ||
| * [ ] post link to python-announce-list@python.org | ||
|
|
||
| ### Post release | ||
|
|
||
| * [ ] cherry-pick change-log modifications to main branch (`master`) | ||
| * [ ] update release checklist template | ||
| * [ ] ping Anaconda Distro team to trigger a build for `defaults` (FINAL ONLY) | ||
| * [ ] close milestone (and then close this release issue) | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Could these just be actual templates?
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. In this directory: https://github.com/numba/numba/tree/master/.github/ISSUE_TEMPLATE
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Maybe. However, I am not sure we can git version control the templates then. I think keeping track of how they evolve might be useful. Maybe we can update the templates from the documentation directly?
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @stuartarchibald that link is useful, I think that would be good then. Do we want to keep a test in the developer docs to link to these templates?
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Maybe I can symlink the templates into Sphinx, let me try that.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The templates are versioned by virtue of them being in the repo? You can see e.g. blame from numerous changes to the bug report template here: or do you mean something else?
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
I wasn't aware that this is how tempaltes worked. I though they were simply attached to the repo in an unversioned form. Thank you for clearing this up.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. No problem. What's also quite nice about maybe doing it this way is that you don't have to expose the template in the https://github.com/numba/numba/blob/master/.github/ISSUE_TEMPLATE/config.yml (as it's not useful to users) but I think it's still accessible directly as needed. E.g. by accessing:
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That is useful, I have included such URLs for both templates. |
||
Uh oh!
There was an error while loading. Please reload this page.