pylint-dev/pylint

Better release notes generation and automated release process

Open

#7.362 geöffnet am 26. Aug. 2022

Auf GitHub ansehen
 (6 Kommentare) (0 Reaktionen) (0 zugewiesene Personen)Python (1.059 Forks)batch import
Enhancement ✨Good first issueHacktoberfestHelp wanted 🙏MaintenanceMinor 💅

Repository-Metriken

Stars
 (4.978 Stars)
PR-Merge-Metriken
 (Durchschn. Merge 58T 21h) (63 gemergte PRs in 30 T)

Beschreibung

Current problem

  • We have to cherry-pick manually #7776
  • contributor-txt pollutes the contributor file with a header because it does not detect the existing header fixed in #7656
  • The contributor needs to be sorted manually because contributor-txt does not handle it
  • The release notes are generated as rst but github want markdown
  • The new release note file is not included in any toctree
  • Only the first link is generated when there is two or more issues referenced in a fragment
  • if false-positive is used instead of false_positive the changelog check is green but the result is not automatically added to the release note see #7369 #7903
  • The release note generated from patch create a duplicated title #7393 fixed in #7589
  • The release date is not automatically added in the documentation (0fba80c8c)
  • Consider automating the deduplication of changelog fragments during patch releases (ref #9301)

Desired solution

Markdown creation so it can be used in both context, other issue automatically fixed

Additional context

Noticed during the release of 2.15.0.

Contributor Guide

Research-Richtung
Das Issue beschreibt mehrere verbleibende Aufgaben: Konvertieren der Release Notes von RST zu Markdown, Sicherstellen, dass neue Notizdateien in einem toctree enthalten sind, Umgang mit mehreren Issue Referenzen in einem Fragment und Automatisierung der Deduplizierung. Untersuche den aktuellen Release Prozess im pylint Repository, insbesondere die towncrier Konfiguration und das Release Skript (wahrscheinlich in `scripts/` oder `Makefile`). Siehe dir aktuelle PRs wie #9301 für den Kontext zur Deduplizierung an. Das Ziel ist, einen konkreten Plan zur Automatisierung dieser Schritte vorzuschlagen, möglicherweise durch Änderung des CI Workflows oder der towncrier Konfiguration.
Tech Stack
python
Domain
releasedocumentationtooling
Issue Type
Funktion
SchwierigkeitGeschätzte Implementierungsschwierigkeit für neue Contributors, von 1 für sehr kleine Änderungen bis 5 für Expertenarbeit.
4
Geschätzte ZeitEin grober Zeitrahmen, um zu recherchieren, zu implementieren, zu testen und einen Pull Request vorzubereiten.
Über 1 Woche
AktivitätsstatusWie verfügbar das Issue gerade wirkt: frisch, aktiv, stale, blockiert oder wartet auf Maintainer-Input.
Veraltet
KlarheitWie klar das Issue die erwartete Änderung, Akzeptanzkriterien und den nächsten Schritt erklärt.
Meist klar
Voraussetzungen
Pythonrelease engineering basicsfamiliarity with towncrier
EinsteigerfreundlichkeitEin Score von 1 bis 100, der schätzt, wie zugänglich dieses Issue für First-Time Contributors ist.
25