Conversation
* This is a rough draft of the steps needed to perform a release of GFDL. It is basically a much simpler version of the process I use for releasing SciPy, since we do not have compiled code at this time, and because we are currently a small project with few consumers (so it can only get more complicated... but this is a start...).
There was a problem hiding this comment.
This information is really only for developers doing a release, so doesn't really need to be dumped right on the landing page. I'm just working fast because quite busy. Feel free to help relocate this sensibly.
There was a problem hiding this comment.
Moved to a separate location.
docs/source/index.rst
Outdated
| are named following this convention: ``maintenance/0.1.x`` for the ``0.1.x`` | ||
| release series, ``maintenance/0.2.x`` for the ``0.2.x`` release series, and | ||
| so on. This allows bug fixes to be backported to maintenance branches while | ||
| the ``main`` branch continues to gain new features. |
There was a problem hiding this comment.
let me know if you want to do it differently--I've been doing it this way for SciPy for almost a decade, so used to it...
docs/source/index.rst
Outdated
| the tag is signed--make sure you are properly setup for signing tags). | ||
| #. Continue with building release artifacts. | ||
| #. Since we are currently a pure Python project, go ahead and build the source | ||
| distribution and binary (wheel) locally: ``python -m build``. If that |
There was a problem hiding this comment.
Since we are a pure Python project for now, I'm pretty sure the wheels you build on any platform, will run just fine on any other platform. If we ever add compiled code, that goes completely out the window of course.
Also, building release artifacts on your local machine really isn't ideal for security. Some notes on this:
- We should eventually build the release artifacts in CI and upload them from there, which does get recognized when done properly via trusted releases: https://docs.pypi.org/trusted-publishers/. I just don't have the bandwidth for doing that right now. Feel free to open an issue about that and/or help out...
- We should provide the "hashes" of our release artifacts for security reasons. I don't have the bandwidth to set that up at the moment, but it is really just a matter of copying how an upstream project does that (could just "borrow" from SciPy again) and dumping the hashes from the hashing script in to the relnotes. Feel free to open an issue about this and/or help me with it.
One thing I did do--turned on immutable releases for our project, which helps with security a little bit: https://docs.github.com/en/code-security/concepts/supply-chain-security/immutable-releases
docs/source/index.rst
Outdated
| the GUI at https://github.com/lanl/GFDL/releases to create a release and | ||
| upload all release artifacts. At this stage you can push up the release | ||
| tag so that it may be used for the GitHub release: ``git push origin v0.1.0``. | ||
| #. Update the deployed documentation following the release. |
There was a problem hiding this comment.
I think this process will be setup by Navamita. GitHub pages has a storage limit that is a problem for some large projects, but is maybe "ok" for us for now. readthedocs is maybe slow and has ads. Each option likely has drawbacks.
docs/source/index.rst
Outdated
| api/index No newline at end of file | ||
| api/index | ||
|
|
||
| Process for Making a Release |
There was a problem hiding this comment.
Note that this is only for a PyPI + GitHub release, which is what I have experience with. conda-forge is a different beast, and I don't currently see a champion for the conda-forge release process in gh-1. As it stands, that probably means it won't happen in the coming week, but feel free to step up and handle (and document) that part of the process.
I suspect I will be the release manager to start things off, but it would be nice if I can hand that process off to a trainee eventually, at least while the project is funded (since it is also a good learning experience for them).