Refresh the current-release references in SECURITY.md after v0.0.2-beta
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 1/5
- Tempo stimato
- Meno di un'ora
- Idoneità per principianti
- 95/100
- Tipo di issue
- Documentazione
- Chiarezza
- Specificata chiaramente
- Stato di attività
- Attiva
- Ambito
- documentation
Direzione di ricerca
Inizia leggendo SECURITY.md intorno alla riga 5 e confronta il suo riferimento alla versione corrente, la data, l’URL del tag e la sezione sulle versioni supportate con la release v0.0.2-beta. Aggiorna soltanto le informazioni obsolete sulla release, preservando le dichiarazioni sul supporto delle versioni precedenti e le istruzioni per la segnalazione delle vulnerabilità. Conferma che gli URL reali dei tag e la politica esistente per le correzioni di sicurezza rimangano invariati.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Audited against merged master 13289d7a74ad45561554bbb6673a189dbb192a27 (PR #161).
Problem
SECURITY.md still calls v0.0.1 (2026-08-23) the current public release and does not mention v0.0.2-beta.
GitHub currently identifies v0.0.2-beta, published 2026-10-15, as the latest release. This factual documentation drift appeared after the earlier v0.0.1 documentation work in #75.
Scope and acceptance
- Correct the current-release sentence, date and release link to identify the actual latest release.
- Ensure the supported-version section accounts for the current release under the existing security-fix policy.
- Preserve the stated support status of older versions; do not silently invent an end-of-support policy.
- Preserve vulnerability-reporting instructions.
- Use real tag URLs: the old release's display name is
v0.0.1-beta, but its actual tag remainsv0.0.1.
This is a documentation correction only; do not rename releases/tags or alter security reporting configuration.
Starting points
This is a bounded follow-up suitable for a first contribution; no broader feature redesign is requested.
- Lingua principale
- Rust
- Stelle
- 1
- Fork
- 3
- Merge medio
- 6h 43m
- PR unite (30g)
- 15
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
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 wavefnd/Vex
-
bug ci cross-platform good first issue
Difficoltà 2/5 1-3 ore Idoneità per principianti 90/100
I maintainer di solito rispondono entro 1 giorno
-
bug good first issue tooling
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
I maintainer di solito rispondono entro 1 giorno
-
build cross-platform enhancement good first issue
Difficoltà 2/5 1-3 ore Idoneità per principianti 90/100
I maintainer di solito rispondono entro 1 giorno
-
bug good first issue ui/ux
Difficoltà 2/5 1-3 ore Idoneità per principianti 91/100
I maintainer di solito rispondono entro 1 giorno
-
bug good first issue ui/ux
Difficoltà 2/5 Mezza giornata Idoneità per principianti 90/100
I maintainer di solito rispondono entro 1 giorno
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 66/100
git-ai-project/git-ai#2434 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
peteonrails/voxtype#909 ·
I maintainer di solito rispondono entro 2 giorni
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
kucherenko/jscpd#1239 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 69/100
alchemyplatform/rundler#1358 ·
I maintainer di solito rispondono entro 3 giorni