Skip to content

DOC: document the process for releasing#39

Merged
nray merged 3 commits intomainfrom
treddy_document_release_process
Feb 5, 2026
Merged

DOC: document the process for releasing#39
nray merged 3 commits intomainfrom
treddy_document_release_process

Conversation

@tylerjereddy
Copy link
Collaborator

  • 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...).

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).

* 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...).
@tylerjereddy tylerjereddy added this to the 0.1.0 milestone Jan 31, 2026
@tylerjereddy tylerjereddy added the documentation Improvements or additions to documentation label Jan 31, 2026
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Moved to a separate location.

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.
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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...

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
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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:

  1. 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...
  2. 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

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.
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will be a in a separate PR

api/index No newline at end of file
api/index

Process for Making a Release
Copy link
Collaborator Author

@tylerjereddy tylerjereddy Jan 31, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@nray nray merged commit 6c21394 into main Feb 5, 2026
18 checks passed
@nray nray deleted the treddy_document_release_process branch February 5, 2026 00:35
@tylerjereddy tylerjereddy changed the title WIP, DOC: document the process for releasing DOC: document the process for releasing Feb 5, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

documentation Improvements or additions to documentation

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants