Release cadence: observations and a possible automation offer

[jahirvidrio]

Hi Eugene,

I noticed master is about 42 commits ahead of the 1.10.0 tag (Dec 2025), with around 15 PRs merged since then. I wanted to ask before assuming anything about the cadence.

Looking at the tag history, releases seem to follow an annual rhythm (1.6 → 1.7 → 1.8 → 1.9 → 1.10, with 11-18 month gaps). Is that intentional, or would you be open to publishing more frequently?

If automation would help, I'm happy to send a PR adding .github/workflows/release.yml based on PyPI trusted publishing (no secrets in the repo, OIDC based). I would keep it conservative: only tag pushes trigger it, you keep full control of when to cut a release. If you'd rather keep releases manual for whatever reason (you know the project better than I do), that's completely fine, I just wanted to surface the question instead of guessing.

Either way, thanks for maintaining nodeenv, it's a small tool but it saves a lot of friction.

[ekalinin]

Hi Jahir,

Thanks for raising this, and for checking the numbers. The gaps between releases aren't a policy. I'll cut 1.11.0 from current master soon.

A trusted publishing workflow would be welcome. Please keep it to tag pushes only, pin actions by SHA, grant id-token: write only to the publish job, run it in a pypi environment, build with python -m build, and fail if the tag doesn't match nodeenv_version in nodeenv.py. I'll configure the publisher on the PyPI side.

[jahirvidrio]

I noticed 1.11.0 already went out, thanks for moving on that so quickly.

Confirmed from the tag history: bare version, no v prefix. That simplifies the "tag must equal nodeenv_version" check. The rest of your guard rails stay as listed: SHA-pinned actions, id-token: write confined to the publish job, python -m build, run inside a pypi environment. I'll keep the change to a single workflow file so the diff stays narrow.

I'll come back here with the workflow in a comment (not a PR yet) so you can sanity-check the structure before I open it. Expect something within the next few days.

[jahirvidrio]

Two questions on action versions before I start drafting the trusted-publishing workflow.

Observation first: the repo's existing workflows don't agree on majors. main.yml uses checkout@v5, setup-python@v6, upload-artifact@v6, download-artifact@v7. tests.yml is one major behind on each it uses: checkout@v4, setup-python@v5, upload-artifact@v4. So there's drift already.

Which majors should release.yml use?

1. Match main.yml (v5/v6/v6/v7).
2. Match tests.yml's baseline (v4/v5/v4 for the actions it uses; for download-artifact please tell me which major you'd want since tests.yml doesn't use it).
3. Track latest stable (checkout@v7.0.1, setup-python@v7.0.0, upload-artifact@v7.0.1, download-artifact@v8.0.1). Newest available, no migration debt to carry later.

My preference is option 3, but I'd rather have your input before drafting.

Should this PR also align main.yml and tests.yml to the same majors, or stay focused on release.yml and leave the existing drift for a future PR?

Either way works. Tell me what you'd prefer and I'll get started.