कन्वेंशनल कमिट्स चेंजलॉग बिल्डर स्किल

--- name: conventional-commits-changelog-builder description: एक git log को Conventional Commits प्रारूप में बदलकर तैयार-पेस्ट Keep a Changelog रिलीज़ अनुभाग में बदलता है - Added, Changed, Deprecated, Removed, Fixed, Security - scopes, issue और commit लिंक तथा breaking-changes ब्लॉक के साथ। बिना migration नोट्स वाले breaking changes, non-conforming और fixup commits, reverts और duplicates को फ्लैग करता है, और अगला SemVer संस्करण सुझाता है। इसमें --self-test के साथ एक ऑफ़लाइन stdlib Python बिल्डर शामिल है। --- # Conventional Commits Changelog Builder आप maintainers को पिछले टैग के बाद के commits को एक ऐसे changelog प्रविष्टि में बदलने में मदद करते हैं जिसे लोग वास्तव में पढ़ सकें। इसे हाथ से लिखने का मतलब है लॉग को स्क्रॉल करना, अनुमान लगाना कि कौन से commits मायने रखते हैं, और footer में छिपे एक breaking change को भूल जाना। इसे जनरेट करना हर typo, WIP commit और reverted feature को रिलीज़ में अंधाधुंध कॉपी कर देता है। आप commits को पार्स करते हैं, उन्हें Keep a Changelog अनुभागों में मैप करते हैं, सूचीबद्ध करते हैं कि वास्तव में क्या छोड़ा गया और क्यों, और बताते हैं कि रिलीज़ को कौन सा संस्करण मिलना चाहिए। ## इस skill में फ़ाइलें - `scripts/changelog_build.py` - `git log` (डिफ़ॉल्ट प्रारूप), `git log --oneline` या `%x1f`/`%x1e` रिकॉर्ड्स एक्सपोर्ट पढ़ता है; `type(scope)!: description` हेडर और `BREAKING CHANGE:` फ़ुटर पार्स करता है; Added / Changed / Deprecated / Removed / Fixed / Security में BREAKING CHANGES ब्लॉक के साथ समूहित करता है; रेंज में मौजूद reverts को रद्द करता है, merges को छोड़ता है, डुप्लिकेट हटाता है, सुझाए गए हेडर के साथ fixup/WIP और non-conforming commits को फ्लैग करता है; issues, commits और compare रेंज को लिंक करता है; SemVer bump सुझाता है (0.x के प्रति जागरूक); मौजूदा CHANGELOG.md में अनुभाग डाल सकता है (केवल Python 3.8+ मानक पुस्तकालय) - `references/commit-to-changelog-mapping.md` - type -> अनुभाग तालिका, breaking-change नियम, bump नियम और खोज कोड CC01-CC10 - `references/release-hygiene.md` - उपयोगकर्ताओं के लिए प्रविष्टियाँ लिखना, migration नोट्स, non-conforming इतिहास के साथ क्या करना है, और CI जाँच - `templates/release-notes-review.md` - अनुभाग के साथ वापस देने के लिए समीक्षा - `examples/git-log.txt` - v2.3.1 के बाद से एक काल्पनिक CLI (tidyq) के 21 commits: दो breaking changes, एक security fix, एक deprecation, एक revert, एक डुप्लिकेट cherry-pick, एक fixup, एक WIP और एक सादा "Fixed ..." commit - `examples/CHANGELOG.md` - प्रोजेक्ट का मौजूदा changelog (Unreleased + 2.3.1 + 2.3.0) - `examples/changelog-report.md` - उस लॉग पर वास्तविक बिल्डर आउटपुट ## कार्यप्रवाह ### 1. Commit रेंज प्राप्त करें अंतिम रिलीज़ किया गया टैग पूछें और उसके बाद सब कुछ निर्यात करें, नवीनतम पहले: ``` git log v2.3.1..HEAD > commits.txt git log v2.3.1..HEAD --format='%H%x1f%s%x1f%b%x1e' > commits.txt # सबसे सुरक्षित: बॉडी रखता है, कोई पार्सिंग अनुमान नहीं ``` वर्तमान संस्करण, रिलीज़ तिथि, रिपॉजिटरी URL (लिंक के लिए), टैग उपसर्ग (डिफ़ॉल्ट `v`) और क्या आंतरिक commits (refactor, docs, ci, chore, test) सूचीबद्ध किए जाने चाहिए, यह भी पूछें। एक squash-merge कार्यप्रवाह आदर्श है: एक PR = एक commit = एक पंक्ति। ### 2. बिल्डर चलाएँ ``` python3 scripts/changelog_build.py examples/git-log.txt --current 2.3.1 --date 2026-11-03 --repo-url https://github.com/tidyq/tidyq python3 scripts/changelog_build.py commits.txt --current 2.3.1 --insert CHANGELOG.md > CHANGELOG.new.md python3 scripts/changelog_build.py commits.txt --current 0.9.4 --include-internal --json python3 scripts/changelog_build.py --self-test ``` Exit 0 = टैग करने के लिए तैयार, 1 = उच्च खोजें, 2 = खराब इनपुट। शेल के बिना, `references/commit-to-changelog-mapping.md` को हाथ से लागू करें: प्रत्येक हेडर पार्स करें, type को अनुभाग में मैप करें, `!` और `BREAKING CHANGE:` फ़ुटर इकट्ठा करें, reverts रद्द करें, फिर उच्चतम bump चुनें। ### 3. टैग करने से पहले खोजों को ठीक करें - CC03 (उच्च): बिना `BREAKING CHANGE:` फ़ुटर वाला एक `!` commit उपयोगकर्ताओं को कोई migration पथ नहीं देता। नोट (क्या टूटता है, इसके बजाय क्या करें) अनुभाग में लिखें। - CC08 (उच्च): non-conforming commits जो सुविधाओं या फिक्स की तरह दिखते हैं, changelog से गायब हैं। सुझाए गए हेडर के साथ उन्हें हाथ से जोड़ें, और commit-lint जाँच चालू करें। - CC07: fixup/WIP commits को रिलीज़ से पहले squash किया जाना चाहिए; CC04: पुराने रिलीज़ के reverts को एक वाक्य की आवश्यकता होती है जो बताए कि क्यों। - CC01/CC02/CC05/CC06: शब्दांकन और अनुरूपता; प्रकाशित इतिहास को फिर से लिखने के बजाय changelog टेक्स्ट में ठीक करें। ### 4. मनुष्यों के लिए संपादित करें बिल्डर आपको सही संरचना देता है, अच्छा गद्य नहीं। प्रविष्टियों को उपयोगकर्ता-दृश्यमान प्रभावों के रूप में फिर से लिखें ("Export writes Parquet by default" बजाय "refactor writer"), एक परिवर्तन का वर्णन करने वाली प्रविष्टियों को मर्ज करें, उन scopes को रखें जिन्हें उपयोगकर्ता पहचानते हैं, और BREAKING CHANGES ब्लॉक को ऐसी जगह रखें जहाँ कोई इसे मिस न कर सके। `references/release-hygiene.md` देखें। ### 5. डिलीवर करें `templates/release-notes-review.md` भरें: संस्करण और क्यों, अंतिम अनुभाग, migration नोट्स, क्या छोड़ा गया, और अनुवर्ती (commitlint, PR शीर्षक जाँच)। `--insert` के साथ, अद्यतन CHANGELOG.md वापस सौंपें; मूल फ़ाइल कभी संशोधित नहीं होती। ## उदाहरण परिणाम `examples/git-log.txt` (वर्तमान 2.3.1) पर बिल्डर 21 commits पढ़ता है, 85% अनुरूप, और **3.0.0** सुझाता है: `feat(export)!` Parquet को डिफ़ॉल्ट बनाता है (उचित BREAKING CHANGE फ़ुटर के साथ) और `fix(config)!` बिना किसी migration नोट के INI कॉन्फ़िग फ़ाइल को हटा देता है (CC03, उच्च)। "Fixed crash when the config file is empty" एक Conventional Commit नहीं है और चुपचाप changelog से मिस हो जाएगा (CC08, उच्च; सुझाया गया `fix: crash when the config file is empty`)। टोकन-लीक फिक्स Security के अंतर्गत आता है, `--legacy-dates` deprecation Deprecated के अंतर्गत, रंग-थीम सुविधा और इसका revert एक दूसरे को रद्द करते हैं, cherry-picked BOM फिक्स एक बार सूचीबद्ध है, और merge, fixup, WIP और 5 आंतरिक commits को छोड़े गए के रूप में सूचीबद्ध किया गया है। ## नियम - कभी भी प्रविष्टियाँ न बनाएँ: हर पंक्ति एक commit से आती है, और हर commit या तो अनुभाग में या "छोड़े गए" सूची में होता है। - एक breaking change को हमेशा migration नोट और major bump मिलता है (0.x पर minor); इसे कभी भी Changed में न छिपाएँ। - Security फिक्स Security के अंतर्गत जाते हैं, भले ही commit type `fix` हो। - commit संदेशों को ठीक करने के लिए प्रकाशित इतिहास को फिर से न लिखें; changelog टेक्स्ट ठीक करें और भविष्य के लिए lint जाँच जोड़ें। - नवीनतम रिलीज़ को शीर्ष पर रखें, तिथियाँ YYYY-MM-DD के रूप में और प्रति संस्करण एक compare लिंक। - संस्करण एक सुझाव है: maintainer निर्णय लेता है, विशेष रूप से `fix` के रूप में टाइप किए गए व्यवहार परिवर्तनों के लिए।