Repository navigation
document release checklist - #6986
Conversation
This adds documentation and templates for the Numba release process.
| .. 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 | ||
| ------------------------------------------------------------- | ||
|
|
||
| A patch release usually involves a series of cherry-picks, so the recipe is | ||
| slightly different. | ||
|
|
||
| .. 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) |
There was a problem hiding this comment.
Could these just be actual templates?
There was a problem hiding this comment.
In this directory: https://github.com/numba/numba/tree/master/.github/ISSUE_TEMPLATE
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
@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?
There was a problem hiding this comment.
Maybe I can symlink the templates into Sphinx, let me try that.
There was a problem hiding this comment.
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:
https://github.com/numba/numba/blame/master/.github/ISSUE_TEMPLATE/Bug_report.md
or do you mean something else?
There was a problem hiding this comment.
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:
https://github.com/numba/numba/blame/master/.github/ISSUE_TEMPLATE/Bug_report.mdor do you mean something else?
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.
There was a problem hiding this comment.
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:
https://github.com/numba/numba/issues/new?template=THE_RELEASE_TEMPLATE.md
There was a problem hiding this comment.
That is useful, I have included such URLs for both templates.
This makes the templates available from the menu to open issues. It also displays a description and the template itself as part of the Sphinx based documentation.
|
@stuartarchibald I have managed to convert the plain text templates to proper Github templates. I added the suffix (Maintainer Only) to the description for now, as I haven't yet found the documentation about hiding issue templates (I am not even sure it is possible). |
|
@stuartarchibald I have trawled the Github documentation some more and have not discovered a setting for |
stuartarchibald
left a comment
There was a problem hiding this comment.
Thanks for the patch, great to see this recorded and made easy to do.
| 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 | ||
| all potential tasks. All templates within this document are written in Github | ||
| Markdown and are available as issue templates on Github. This means, |
There was a problem hiding this comment.
Why are they called .yml as files in the doc source tree if they are markdown .md?
There was a problem hiding this comment.
Because the format of the templates is such that you write markdown for the template content and then wrap that in yaml to add metadata such as title etc...
There was a problem hiding this comment.
So, this piece of documentation threw me off:
Issue templates are stored on the repository's default branch, in a hidden .github/ISSUE_TEMPLATE directory. If you create a template in another branch, it will not be available for collaborators to use. Issue template filenames are not case sensitive, and need a .md extension. To be included in the community profile checklist, issue templates must be located in the .github/ISSUE_TEMPLATE folder and contain valid name: and about: YAML front matter.
Will rename the files to .md.
Tweaking some language, consistency and formatting bits. Co-authored-by: stuartarchibald <stuartarchibald@users.noreply.github.com>
|
@stuartarchibald thank you for your review. I have addressed most issues and left a few comments on items where we need to find consensus. Happy to see this moving closer to the finish line. |
As title
As title
stuartarchibald
left a comment
There was a problem hiding this comment.
Thanks for the updates. Few minor suggestions else looks good.
As title. Co-authored-by: stuartarchibald <stuartarchibald@users.noreply.github.com>
As title
stuartarchibald
left a comment
There was a problem hiding this comment.
Thanks for all your efforts on this, patch looks good!
|
@stuartarchibald thank you for the feedback, I have included all suggestions now and also added the full-stops and capitals as per our OOB conversation. |
This adds documentation and templates for the Numba release process.