Skip to main content

prepare-changelog

Guidelines for preparing changelog entries for nextest releases following Keep a Changelog format

الانتقال إلى التثبيت

معلومات المصدر

المستودع
nextest-rs/nextest
آخر نشاط في المصدر
٤ يناير ٢٠٢٦ في ٢٢:٠٥
لغة SKILL.md المكتشفة
الإنجليزية
النجوم
٣٬٢٩٣
التفرعات
١٧٥

خيارات التثبيت

يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.

مراجعة ملفات المصدر

اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.

عرض SKILL.md

SKILL.md
تعليمات المصدر · معاينة للقراءة فقط
name
prepare-changelog
description
Guidelines for preparing changelog entries for nextest releases following Keep a Changelog format
# Changelog Format Guide This document describes the format and conventions used in `site/src/changelog.md`. ## Overall Structure The changelog follows the [Keep a Changelog](https://keepachangelog.com/) format with nextest-specific conventions. ### Version Header ```markdown ## [X.Y.Z] - YYYY-MM-DD ``` - Version numbers are in brackets - Date is in ISO 8601 format (YYYY-MM-DD) - Each version must have a corresponding link at the bottom of the file. ## Section Organization Sections should appear in this order (only include sections that are relevant): 1. **Added** - New features 2. **Changed** - Changes to existing functionality 3. **Fixed** - Bug fixes 4. **Deprecated** - Soon-to-be removed features 5. **Removed** - Removed features 6. **Security** - Security-related changes 7. **Known issues** - Known problems with this release 8. **Miscellaneous** - Other notable changes that don't fit elsewhere 9. **Internal improvements** - Internal changes that may interest contributors ### Section Style - Use `###` for section headers (e.g., `### Added`) - Each section contains bullet points starting with `-` - Indent sub-bullets with two spaces ## Content Guidelines ### What to Include - User-visible changes and new features - Bug fixes that affect users - Performance improvements - Breaking changes (clearly marked) - MSRV (Minimum Supported Rust Version) changes - Security updates ### What to Exclude - Internal dependency updates - Internal refactoring (unless it has user-visible effects) - Documentation-only changes to the site - CI/CD workflow changes - Dependency updates for minor versions (can be grouped) ### Writing Style 1. **Be concise but descriptive**: Each bullet should clearly explain what changed and why it matters 2. **Use present tense**: "Nextest now supports..." not "Nextest now supported..." 3. **Link to documentation**: When introducing features, link to relevant docs with the full URL path 4. **Include context**: Explain the motivation or benefit when it's not obvious ### Examples Good: ```markdown - Nextest can now update itself! Once this version is installed, simply run `cargo nextest self update` to update to the latest version. ``` Good (with note to distributors): ```markdown - Nextest now sets `NEXTEST_LD_*` and `NEXTEST_DYLD_*` environment variables to work around macOS System Integrity Protection sanitization. > Note to distributors: ... ``` Good (with forward-looking context): ```markdown - A new `threads-required` configuration that can be specified as a per-test override. This can be used to limit concurrency for heavier tests, to avoid overwhelming CPU or running out of memory. ``` ## Links and References ### PR and Issue Links - Use inline links: `([#2618])` - Define the link at the end of the section or version: `[#2618]: https://github.com/nextest-rs/nextest/pull/2618` - For pull requests, use the `/pull/` URL - For issues, use the `/issues/` URL ### External Links - Use inline markdown links: `[text](URL)` - Examples: `[GHSA-xxxx](https://github.com/advisories/GHSA-xxxx)`, `[CVE-xxxx](https://nvd.nist.gov/vuln/detail/CVE-xxxx)` ## Contributor Attribution ### First-time Contributors Always thank first-time contributors using this format (use GitHub username only, not full name): ```markdown Thanks [username](https://github.com/username) for your first contribution! ``` Place the attribution: - At the end of the bullet point if it's a single change - At the end of the section if multiple related changes Examples: ```markdown - New feature that does something. Thanks [alice](https://github.com/alice) for your first contribution! ``` ```markdown ### Added - Feature A - Feature B Thanks [bob](https://github.com/bob) for your first contribution! ``` ### Returning Contributors For contributors who have contributed before, you can optionally thank them but don't say "first contribution": ```markdown Thanks [charlie](https://github.com/charlie) for your contribution! ``` Or simply: ```markdown Thanks [charlie](https://github.com/charlie)! ``` ### Multiple Contributors When multiple people contributed to a feature: ```markdown Thanks [alice](https://github.com/alice) and [bob](https://github.com/bob) for your contributions! ``` ## Special Notations ### Notes to Distributors Use blockquotes for notes to distributors or package maintainers: ```markdown > Note to distributors: you can disable self-update by building cargo-nextest with `--no-default-features`. ``` ### Upcoming Changes For warning about future behavior changes: ```markdown ### Upcoming behavior changes If no tests are run, nextest will start exiting with the advisory code **4** in versions released after 2024-11-18. See [discussion #1646](https://github.com/nextest-rs/nextest/discussions/1646) for more. ``` ### Experimental Features Clearly mark experimental features: ```markdown - Experimental support for [feature name](link). Please try them out, and provide feedback in the [tracking issue](link)! ``` ### Breaking Changes If a release contains breaking changes, consider adding a note at the top: ```markdown This is a major release with several new features. It's gone through a period of beta testing, but if you run into issues please [file a bug]! ``` ## Formatting Conventions ### Code and Commands - Use backticks for inline code: `` `cargo nextest run` `` - Use triple backticks for code blocks with language specification: ` ```toml `, ` ```bash ` ### Configuration Examples When showing configuration: ```markdown For example, to time out after 120 seconds: ```toml slow-timeout = { period = "60s", terminate-after = 2 } ``` ``` Note the indentation for the code block within a bullet point. ### Environment Variables - Use all caps with backticks: `` `NEXTEST_RETRIES` `` - Use the format `` `NAME=value` `` when showing how to set them ### Version References - Cargo versions: "Cargo 1.87" - Rust versions: "Rust 1.64" - Nextest versions: "nextest 0.9.100" or "version 0.9.100" ## Dependency Updates List major dependency updates or security updates separately: ```markdown - Update rust-openssl for [CVE-2025-24898](https://nvd.nist.gov/vuln/detail/CVE-2025-24898). ``` ## Examples of Well-Formed Entries ### Simple Feature Addition ```markdown ### Added - A new `--hide-progress-bar` option (environment variable `NEXTEST_HIDE_PROGRESS_BAR`) forces the progress bar to be hidden. Thanks [Remo Senekowitsch](https://github.com/remlse) for your first contribution! ``` ### Complex Feature with Documentation ```markdown ### Added - Nextest now supports assigning [test priorities](https://nexte.st/docs/configuration/test-priorities) via configuration. ``` ### Bug Fix with Issue Link ```markdown ### Fixed - Fixed an occasional hang on Linux with [libtest JSON output](https://nexte.st/docs/machine-readable/libtest-json/). For more details, see [#2316]. [#2316]: https://github.com/nextest-rs/nextest/pull/2316 ``` ### Breaking Change ```markdown ### Changed - If nextest is unable to parse `--target` (and in particular, a custom target), it now fails rather than printing a warning and assuming the host platform. This is being treated as a bugfix because the previous behavior was incorrect. ``` ## Determining What Changed To generate a changelog entry: 1. Get the commit list: `git log <previous-tag>..main --oneline` 2. Review each commit to determine if it's user-visible 3. Group related commits together (e.g., multiple USDT commits into one feature) 4. Check for first-time contributors: `git log --all --author="Name" --oneline | wc -l` 5. Get PR author GitHub username: `gh pr view <number> --json author --jq '.author.login'` 6. Examine key commits for context: `git show <commit> --stat` Filter out: - Documentation site updates (unless they document new features) - CI configuration changes - Internal refactoring without user impact - Most dependency updates (group them together)
عرض على GitHub