Document our release cadence

[asteiker]

Per discussion at our 3 Feb 2026 Hackday:

We would like to release more often, and utilize our Hackday (now Collaboration Cafe) events to release during that time, so others can learn how.

Initially we could aim for quarterly releases. @danielfromearth proposed:

• Month 1: take stock of last release, envision next one
• Month 2: start nailing down what might be in next release
• Month 3: prep for release and release

We already have documentation on the release process itself (https://earthaccess.readthedocs.io/en/stable/contributing/releasing/) so this additional documentation can complement this, either as an addition to the current page or we can create a sub-section on releases.

We ought to consider how to actually put this into practice. Can we modify our hackday template to ensure releases are discussed? Other ways to automate release PR's, etc.?

[mfisher87]

We ought to consider how to actually put this into practice. Can we modify our hackday template to ensure releases are discussed?

This is my biggest concern -- that in documenting a release cadence we make a promise that is hard to keep, and that breaking the promise can reduce trust in the project.

Maybe one solution is to use the community calendar to drive release meetings separately from collaboration cafes. I know I"m always tempted by something excited at collaboration cafes and can't be trusted to focus on a release ;) IMO collaboration cafes are for hard problems where we need multiple brains the most. Releasing can occasionally include decision-making, but most of the time it's pretty boring.

If we can have someone (a Release Czar if you will 😉) who hosts those release meetings and herds the cats to make sure the right people participate, I think that's the best way to ensure we keep to a cadence. If we can't do that, I'd advocate for not committing to a release cadence.

[mfisher87]

Initially we could aim for quarterly releases. @danielfromearth proposed:

• Month 1: take stock of last release, envision next one

• Month 2: start nailing down what might be in next release

• Month 3: prep for release and release

If we go with a plan like this, I'd say we'd need monthly release meetings and we'd need an artifact, e.g. a GitHub Milestone, that comes out of those meetings and keeps us on track with our plans.

E.g.

• Month 1: take stock of last release, envision next one. Create a Milestone, give it a title defining the "theme" of the next release. Populate the milestone with all issues closed since the last release.
• Month 2: start nailing down what might be in next release. Populate the milestone with all issues closed since the last meeting. Add open issues we want to include in the next release.
• Month 3: prep for release and release. Populate the milestone with all issues closed since the last meeting. Remove issues we were unable to resolve in time for the release. Close the milestone and release!