DOC: updating the notes on how to release #5190
Conversation
|
So i was just rewriting the instructions for major/minor releases to reflect how we're not really using the That correct @neutrinoceros ? |
|
that is entirely correct ! Now, major releases is another thing we could discuss; none happened under my watch, in the sense that we never did a 5.0 thus far but... |
chrishavlin
force-pushed
the
docs_update_release_info
branch
from
243ef84 to
d61458e
Compare
|
pre-commit.ci autofix |
for more information, see https://pre-commit.ci
|
Maybe I'm forgetting something, but I think this is ready for review. |
|
(I forgot something... just updated the announcement section... now this is ready) |
|
just added a note on what to do if you merge a PR before assigning the backport branch. |
|
Requesting a review from myself. I thought I had given one at last month's workshop but clearly I got carried away doing something else 🫣 |
| describe the necessary steps for each kind of release in detail. | ||
| describe the necessary steps for each kind of release in detail. Several of the | ||
| following steps require that you have write privileges for the main yt GitHub | ||
| repository (if you're reading this, you probably already do). |
doc/source/developing/releasing.rst
Outdated
| This documentation assumes that your local copy of the yt repository has the | ||
| main yt repository as the ``origin`` remote. You can double check with: |
There was a problem hiding this comment.
Interesting. This doesn't match any actively encouraged workflow as far as I know, so maybe it's an opportunity to fix this. I think we should assume https://github.com/yt-project/yt to be named upstream, which is the convention, and matches the setup one gets from gh fork yt-project/yt
There was a problem hiding this comment.
ya, not sure why the steps were initially described with the main repo as origin. and i agree, just changing it to a standard setup would be clearer.
There was a problem hiding this comment.
and i did commit the suggested change below, but i'll leave this comment as a reminder to update these lines.
| deprecated features targeted for removal in the new release are removed from the | ||
| ``main`` branch, ideally in a single PR. Such a PR can be issued at any point |
There was a problem hiding this comment.
this could use some editing too. Deprecation cycles should only be concluded in major releases, as stated earlier, but this section is also about feature releases. Also, we do not specify a "target" version for removals anymore (doing so can create uncalled-for complications when we realize we can't deliver what we promised 2 years back)
| The ``__version__`` variable must be updated. | ||
|
|
||
| Once these files have been updated, commit these updates. This is the commit we | ||
| To update these files, check out and update the branch that will be released (``main`` |
There was a problem hiding this comment.
I can't comment the (unedited) appropriate line, but I note that VERSION doesn't exist in setup.py anymore. Currently, the source of truth is yt._version.__version__
There was a problem hiding this comment.
oh, ya, good catch.
There was a problem hiding this comment.
looks like there's a still a version string in the pyproject.toml as well
There was a problem hiding this comment.
and doc/source/conf.py.
There was a problem hiding this comment.
right, I forgot we didn't have a unique source of truth 🙃
I'm sure I'll find a minute to scratch that itch some other time !
Co-authored-by: Clément Robert <cr52@protonmail.com>
|
thanks for the thorough read @neutrinoceros ! will try to address the remaining comments soon. |
|
@neutrinoceros , got through almost all the comments. didn't have time to update the description of deprecation cycles yet (this comment https://github.com/yt-project/yt/pull/5190/files#r2300779653), will try to do so soon. But feel free to check the other changes in the mean time. |
3 participants
Draft for now, will continue to update this as I work through the 4.4.1 release.I think this is ready!