|
| 1 | +# Changelog.md Guide |
| 2 | + |
| 3 | +## Introduction |
| 4 | + |
| 5 | +The `changelog.md` document serves as a valuable resource for developers and users alike to track the evolution of a project over time. Understanding the structure and purpose of a changelog helps users and contributors stay informed about new features, bug fixes, and other changes introduced in each release. |
| 6 | + |
| 7 | +## What is changelog.md? |
| 8 | + |
| 9 | +`changelog.md` is a file commonly found in Python packages. Its primary purpose is to provide a chronological record of significant changes made to the project with each new release. This document helps users understand what has been added, fixed, or modified in the latest version of the software. In addition, it allows the contributors and users to understand the versioning syntax used for the package. |
| 10 | + |
| 11 | +[Keep a Changelog.md](https://keepachangelog.com/en/1.1.0/) is great, simple resource for understanding what a changelog is, how to create a good changelog, and incliudes some pointers of things to avoid in a changelog. |
| 12 | + |
| 13 | +```{admonition} Semantic Versioning |
| 14 | +:class: tip |
| 15 | +
|
| 16 | +An important component of a package that serves as the backbone behind the changelog file is a good versioning scheme. Semantic Versioning is widely used across Python packages. |
| 17 | +* [Semantic Versioning](https://semver.org) |
| 18 | +``` |
| 19 | + |
| 20 | +## Why is it important? |
| 21 | + |
| 22 | +A well-maintained changelog is essential for transparent communication with users and developers. It serves as a centralized hub for documenting changes and highlights the progress made in each release. By keeping the changelog up-to-date, project maintainers can build trust with their user base and demonstrate their commitment to improving the software. |
| 23 | + |
| 24 | +## What does it include? |
| 25 | + |
| 26 | +The contents of a changelog.md file typically follow a structured format, detailing the changes introduced in each release. While the exact format may vary depending on the project's conventions, some common elements found in changelogs for Python packages include: |
| 27 | + |
| 28 | +- **Versioning**: Clear identification of each release version using semantic versioning or another versioning scheme adopted by the project. |
| 29 | + |
| 30 | +- **Release Date**: The date when each version was released to the public, providing context for the timeline of changes. |
| 31 | + |
| 32 | +- **Change Categories**: Organizing changes into categories such as "Added," "Changed," "Fixed," and "Removed" to facilitate navigation and understanding. |
| 33 | + |
| 34 | +- **Description of Changes**: A concise description of the changes made in each category, including new features, enhancements, bug fixes, and deprecated functionality. |
| 35 | + |
| 36 | +- **Links to Issues or Pull Requests**: References to relevant issue tracker items or pull requests associated with each change, enabling users to access more detailed information if needed. |
| 37 | + |
| 38 | +- **Upgrade Instructions**: Guidance for users on how to upgrade to the latest version, including any breaking changes or migration steps they need to be aware of. |
| 39 | + |
| 40 | +- **Contributor Recognition**: Acknowledgment of contributors who made significant contributions to the release, fostering a sense of community and appreciation for their efforts. |
| 41 | + |
| 42 | +## What does it look like? |
| 43 | + |
| 44 | +```markdown |
| 45 | +# Change Log |
| 46 | +All notable changes to this project will be documented in this file. |
| 47 | + |
| 48 | +The format is based on [Keep a Changelog](http://keepachangelog.com/) |
| 49 | +and this project adheres to [Semantic Versioning](http://semver.org/). |
| 50 | + |
| 51 | +## [Unreleased] - yyyy-mm-dd |
| 52 | + |
| 53 | +Here we write upgrading notes for brands. It's a team effort to make them as |
| 54 | +straightforward as possible. |
| 55 | + |
| 56 | +### Added |
| 57 | +- [PROJECTNAME-XXXX](http://tickets.projectname.com/browse/PROJECTNAME-XXXX) |
| 58 | + MINOR Ticket title goes here. |
| 59 | +- [PROJECTNAME-YYYY](http://tickets.projectname.com/browse/PROJECTNAME-YYYY) |
| 60 | + PATCH Ticket title goes here. |
| 61 | + |
| 62 | +### Changed |
| 63 | + |
| 64 | +### Fixed |
| 65 | + |
| 66 | +## [1.2.4] - 2017-03-15 |
| 67 | + |
| 68 | +Here we would have the update steps for 1.2.4 for people to follow. |
| 69 | + |
| 70 | +### Added |
| 71 | + |
| 72 | +### Changed |
| 73 | + |
| 74 | +- [PROJECTNAME-ZZZZ](http://tickets.projectname.com/browse/PROJECTNAME-ZZZZ) |
| 75 | + PATCH Drupal.org is now used for composer. |
| 76 | + |
| 77 | +### Fixed |
| 78 | + |
| 79 | +- [PROJECTNAME-TTTT](http://tickets.projectname.com/browse/PROJECTNAME-TTTT) |
| 80 | + PATCH Add logic to runsheet teaser delete to delete corresponding |
| 81 | + schedule cards. |
| 82 | + |
| 83 | +## [1.2.3] - 2017-03-14 |
| 84 | + |
| 85 | +### Added |
| 86 | + |
| 87 | +### Changed |
| 88 | + |
| 89 | +### Fixed |
| 90 | + |
| 91 | +- [PROJECTNAME-UUUU](http://tickets.projectname.com/browse/PROJECTNAME-UUUU) |
| 92 | + MINOR Fix module foo tests |
| 93 | +- [PROJECTNAME-RRRR](http://tickets.projectname.com/browse/PROJECTNAME-RRRR) |
| 94 | + MAJOR Module foo's timeline uses the browser timezone for date resolution |
| 95 | +``` |
| 96 | +[Sample changelog source](https://gist.github.com/juampynr/4c18214a8eb554084e21d6e288a18a2c) |
0 commit comments