-
Notifications
You must be signed in to change notification settings - Fork 59
Add: changelog-file.md to the Docs-for-Contributors-and-Maintainers section. #222
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
Changes from all commits
Commits
Show all changes
19 commits
Select commit
Hold shift + click to select a range
14359f3
Add changelog-file.md to documentation/repository-files/ to address g…
miguelalizo 98191d6
Update changelog-file.md to remove typo/codespell.
miguelalizo bb499cd
Update changelog-file.md to remove trailing whitespaces.
miguelalizo 18b0cab
Update changelog-file.md to add a newline at EOF.
miguelalizo 36a53fc
Update changelog-file.md to add call-out to versioning page.
miguelalizo 8584f3e
Update documentation/repository-files/changelog-file.md
miguelalizo 1108dc9
Update documentation/repository-files/changelog-file.md
miguelalizo d3000a9
Update changelog-file.md to address reviewer feedback
miguelalizo 42300e1
Update changelog-file.md to consistely call out CHANGELOG.md
miguelalizo 0de62e3
Update python-package-distribution-files-sdists-wheel.md to ensure co…
miguelalizo c617dc7
Update changelog example to use Devicely's real changelog
miguelalizo 0edda99
Add a 'How do developers use it' section to changelog-file.md
miguelalizo 5048e97
Update documentation/repository-files/changelog-file.md
miguelalizo ae2d435
Update documentation/repository-files/changelog-file.md
miguelalizo bbaf612
Update documentation/repository-files/changelog-file.md
miguelalizo 25961a9
Merge branch 'pyOpenSci:main' into main
miguelalizo 0158d6f
Separate sections of how maintainers use a changelog into their own m…
miguelalizo 4af3f10
Add third level heading for listed info in How do maintainers use it?…
miguelalizo 1e89674
Change wording of change log to changelog
miguelalizo File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,114 @@ | ||
# CHANGELOG.md Guide | ||
|
||
## Introduction | ||
|
||
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. | ||
|
||
## What is CHANGELOG.md? | ||
|
||
The primary purpose of `CHANGELOG.md` is to provide a record of notable changes made to the project with each new release. This document helps users understand what has been added, fixed, modified, or removed with each version of the software. | ||
|
||
[Keep a CHAGELOG.md](https://keepachangelog.com/en/1.1.0/) is a great, simple resource for understanding what a changelog is and how to create a good changelog. It also includes examples of things to avoid. | ||
|
||
```{admonition} Versioning your Python package and semantic versioning | ||
:class: tip | ||
|
||
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. | ||
* [Creating New Versions of Your Python Package](../../package-structure-code/python-package-versions.md) | ||
* [Semantic Versioning](https://semver.org) | ||
``` | ||
|
||
## Why is it important? | ||
|
||
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. | ||
|
||
## What does it include? | ||
|
||
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: | ||
|
||
- **Versioning**: Clear identification of each release version using semantic versioning or another versioning scheme adopted by the project. | ||
|
||
- **Release Date**: The date when each version was released to the public, providing context for the timeline of changes. | ||
|
||
- **Change Categories**: Organizing changes into categories such as "Added," "Changed," "Fixed," and "Removed" to facilitate navigation and understanding. | ||
|
||
- **Description of Changes**: A concise description of the changes made in each category, including new features, enhancements, bug fixes, and deprecated functionality. | ||
|
||
- **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. | ||
|
||
- **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. | ||
|
||
- **Contributor Recognition**: Acknowledgment of contributors who made significant contributions to the release, fostering a sense of community and appreciation for their efforts. | ||
|
||
## How do maintainers use it? | ||
|
||
Often you will see a changelog that documents a few things: | ||
|
||
### Unreleased Section | ||
|
||
Unreleased commits are at the top of the changelog, commonly in an `Unreleased` section. This is where you can add new fixes, updates and features that have been added to the package since the last release. | ||
|
||
This section might look something like this: | ||
|
||
```markdown | ||
miguelalizo marked this conversation as resolved.
Show resolved
Hide resolved
|
||
## Unreleased | ||
* Fix: Fixed a bug.... more here. (@github_username, #issuenumber) | ||
* Add: new feature to... more here. (@github_username, #issuenumber) | ||
``` | ||
|
||
### Release Sections | ||
|
||
When you are ready to make a new release, you can move the elements into a section that is specific to that new release number. | ||
|
||
This specific release section will sit below the unreleased section and can include any updates, additions, deprecations and contributors. | ||
|
||
The unreleased section then always lives at the top of the file and new features continue to be added there. At the same time, after releasing a version like v1.0 all of its features remain in that specific section. | ||
|
||
```markdown | ||
## Unreleased | ||
|
||
## v1.0 | ||
|
||
### Updates | ||
* Fix: Fixed a bug.... more here. (@github_username, #issuenumber) | ||
|
||
### Additions | ||
* Add: new feature to ...more here (@github_username, #issuenumber) | ||
|
||
### Deprecations | ||
|
||
### Contributors to this release | ||
``` | ||
|
||
## What does it look like? | ||
|
||
This example comes from [Devicely](https://github.com/hpi-dhc/devicely/blob/main/CHANGELOG.md), a pyOpenSci accepted package. | ||
|
||
```markdown | ||
# Changelog | ||
All notable changes to this project will be documented in this file. | ||
|
||
The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/), | ||
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html). | ||
|
||
## [Unreleased] | ||
|
||
## [1.1.0] - 2021-08-24 | ||
- removed acceleration magnitude from devicely.EmpaticaReader and devicely.FarosReader since it was out of the scope of the package | ||
- added more flexibility to missing files (e.g. ACC.csv, EDA.csv) to devicely.EmpaticaReader | ||
- changed TagsReader to TimeStampReader to be more consistent with the class naming structure in devicely | ||
- deprecated methods in devicely.SpacelabsReader: set_window and drop_EB | ||
- fixed issue with the timestamp index and fixed column names in devicely.SpacelabsReader | ||
|
||
## [1.0.0] - 2021-07-19 | ||
### Added | ||
- devicely.FarosReader can both read from and write to EDF files and directories | ||
- devicely.FarosReader has as attributes the individual dataframes (ACC, ECG, ...) and not only the joined dataframe | ||
|
||
### Changed | ||
- in devicely.SpacelabsReader, use xml.etree from the standard library instead of third-party "xmltodict" | ||
- switch from setuptools to Poetry | ||
|
||
### Removed | ||
- removed setup.py because static project files such as pyproject.toml are preferred | ||
``` |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is great, but I think real examples are sometimes easier to follow than ones entirely made up. We must have a project already that has a well-maintained changelog (@lwasser ?) that we can copy as an example? We could clip it for the code block and link to the repo for curious reader to dig deeper.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is a great idea. Also, it does seem like the projects will benefit from this guide on changelogs since after going through almost all the projects on PyOpenSci, there is an clear trend of not having a standard for changelogs. Some projects have them as rst files, some projects have them as .txt file and many don't have a changeling at all!
I just added the changelog of Devicely as it is one of the few markdown versions that also follows semver and is based on keep a changelog. The format is not perfect however, since the with the 1.1.0, it seems the project authors stopped using the Added / Changed / Removed subheadings.
Please advice if we'd like to revert back to the template example as opposed to the real example from Devicely if needed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i agree with you both - great suggestion. let's use the real world example rather than a made up one!! and i love that we are also highlighting one of our packages by doing this!