Release cadence: observations and a possible automation offer
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 25/100
Direzione di ricerca
Review the tag history and the proposed .github/workflows/release.yml approach using PyPI trusted publishing. First determine whether the maintainers want a different release cadence or manual releases; done requires an agreed release policy before any automation scope can be defined.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
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.
- Lingua principale
- Python
- Stelle
- 1.8k
- Fork
- 224
- Merge medio
- 10h 15m
- PR unite (30g)
- 22
Preparare l'ambiente
Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di ekalinin/nodeenv
-
docs
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
I maintainer di solito rispondono entro 1 giorno
-
docs
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 90/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
I maintainer di solito rispondono entro 1 giorno
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
I maintainer di solito rispondono entro 1 giorno
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 86/100
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di ekalinin/nodeenv
Issue simili
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 85/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 90/100
I maintainer di solito rispondono entro 1 giorno
-
https://search.utilibre.orgApertainstance instance add
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
searxng/searx-instances#941 · 1 commento ·
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 92/100
FluidNumerics/fluid-walk-blocker#89 ·
I maintainer di solito rispondono entro 1 giorno
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
I maintainer di solito rispondono entro 1 giorno