Skip to content
Merged
Show file tree
Hide file tree
Changes from 8 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 Apr 8, 2024
98191d6
Update changelog-file.md to remove typo/codespell.
miguelalizo Apr 8, 2024
bb499cd
Update changelog-file.md to remove trailing whitespaces.
miguelalizo Apr 8, 2024
18b0cab
Update changelog-file.md to add a newline at EOF.
miguelalizo Apr 8, 2024
36a53fc
Update changelog-file.md to add call-out to versioning page.
miguelalizo Apr 9, 2024
8584f3e
Update documentation/repository-files/changelog-file.md
miguelalizo Apr 9, 2024
1108dc9
Update documentation/repository-files/changelog-file.md
miguelalizo Apr 9, 2024
d3000a9
Update changelog-file.md to address reviewer feedback
miguelalizo Apr 9, 2024
42300e1
Update changelog-file.md to consistely call out CHANGELOG.md
miguelalizo Apr 9, 2024
0de62e3
Update python-package-distribution-files-sdists-wheel.md to ensure co…
miguelalizo Apr 9, 2024
c617dc7
Update changelog example to use Devicely's real changelog
miguelalizo Apr 9, 2024
0edda99
Add a 'How do developers use it' section to changelog-file.md
miguelalizo Apr 9, 2024
5048e97
Update documentation/repository-files/changelog-file.md
miguelalizo Apr 11, 2024
ae2d435
Update documentation/repository-files/changelog-file.md
miguelalizo Apr 11, 2024
bbaf612
Update documentation/repository-files/changelog-file.md
miguelalizo Apr 11, 2024
25961a9
Merge branch 'pyOpenSci:main' into main
miguelalizo Apr 11, 2024
0158d6f
Separate sections of how maintainers use a changelog into their own m…
miguelalizo Apr 11, 2024
4af3f10
Add third level heading for listed info in How do maintainers use it?…
miguelalizo Apr 11, 2024
1e89674
Change wording of change log to changelog
miguelalizo Apr 11, 2024
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
88 changes: 48 additions & 40 deletions documentation/repository-files/changelog-file.md
Original file line number Diff line number Diff line change
@@ -1,19 +1,20 @@
# Changelog.md Guide
# 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.
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?
## What is CHANGELOG.md?

`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.
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 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 includes some pointers of things to avoid in a changelog.
[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} Semantic Versioning
```{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)
```

Expand All @@ -39,58 +40,65 @@ The contents of a changelog.md file typically follow a structured format, detail

- **Contributor Recognition**: Acknowledgment of contributors who made significant contributions to the release, fostering a sense of community and appreciation for their efforts.

## What does it look like?
## How do maintainers use it?

```markdown
# Change Log
All notable changes to this project will be documented in this file.
Often you will see a change log that documents a few things
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Often you will see a change log that documents a few things
Often you will see a changelog that documents a few things

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This sounds like the opener to a bulleted list. But I think the amount of detail that follows is too much for a list, can this be refactored into a full introduction sentence?


The format is based on [Keep a Changelog](http://keepachangelog.com/)
and this project adheres to [Semantic Versioning](http://semver.org/).
Unreleased commits at the top of the changelog, it's common to have 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.

## [Unreleased] - yyyy-mm-dd
This section might look something like this:

Here we write upgrading notes for brands. It's a team effort to make them as
straightforward as possible.
```markdown
## Unreleased
* Fix: Fixed a bug.... more here. (@github_username, #issuenumber)
* Add: new feature to ...more here (@github_username, #issuenumber)
Below the unreleased section, there will be a section for each release. In these sections, you can organize new Fixes, Additions and update together.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This sounds more like the guide and not something readers should copy into a CHANGELOG file.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree. I moved explanation out and cleaned up the section.

## v1.0

### Added
- [PROJECTNAME-XXXX](http://tickets.projectname.com/browse/PROJECTNAME-XXXX)
MINOR Ticket title goes here.
- [PROJECTNAME-YYYY](http://tickets.projectname.com/browse/PROJECTNAME-YYYY)
PATCH Ticket title goes here.
### Updates
* Fix: Fixed a bug.... more here. (@github_username, #issuenumber)

### Changed
### Additions
* Add: new feature to ...more here (@github_username, #issuenumber)

### Deprecations

### Fixed
### Contributors to this release
```

## [1.2.4] - 2017-03-15
When you are ready to make a new release, you can re-organize the list of unreleased elements into a section that is specific to that new release number.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This makes the process of releasing a changelog sound complicated. I think if a maintainer follows the best practices described here making a release can be done by adding 2 lines

 ## Unreleased
+
+ ## v5.12.0

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ahhhh @ucodery this might be partially my fault.

this is what i'm used to seeing

or this

essentially you have a large flowing unreleased section. Then when you go to make a release, you organize into fixed, added, removed/ deprecated contributors.

However your suggest is also good and much simpler. i'm curious what you think? we could stick with the simpler version but add a small breakout on how the changelog might be reorganized for a release (as an option).

Any changelog is better than no changelog so i'm open to thoughts here :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Both valid points! I think it's easier to just see an example of where my thoughts are on this rather than explaining it. I rewrote the section and took somewhat of a hybrid approach. Let me know what you think!

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, that makes more sense, thanks for the examples @lwasser!


Here we would have the update steps for 1.2.4 for people to follow.
The unreleased section then always lives at the top of the file. And as new features are added after release 1.x, they get added to that section.

### Added
## What does it look like?

### Changed
This example comes from [Devicely](https://github.com/hpi-dhc/devicely/tree/main), one of the PyOpenSci reviewed and accepted packages.

- [PROJECTNAME-ZZZZ](http://tickets.projectname.com/browse/PROJECTNAME-ZZZZ)
PATCH Drupal.org is now used for composer.
```markdown
# Changelog
All notable changes to this project will be documented in this file.

### Fixed
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).

- [PROJECTNAME-TTTT](http://tickets.projectname.com/browse/PROJECTNAME-TTTT)
PATCH Add logic to runsheet teaser delete to delete corresponding
schedule cards.
## [Unreleased]

## [1.2.3] - 2017-03-14
## [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

### Fixed

- [PROJECTNAME-UUUU](http://tickets.projectname.com/browse/PROJECTNAME-UUUU)
MINOR Fix module foo tests
- [PROJECTNAME-RRRR](http://tickets.projectname.com/browse/PROJECTNAME-RRRR)
MAJOR Module foo's timeline uses the browser timezone for date resolution
### Removed
- removed setup.py because static project files such as pyproject.toml are preferred
```
[Sample changelog source](https://gist.github.com/juampynr/4c18214a8eb554084e21d6e288a18a2c)
Original file line number Diff line number Diff line change
Expand Up @@ -207,7 +207,7 @@ stravalib-1.1.0.post2-SDist.tar.gz file contents
├─ Makefile
├─ PKG-INFO
├─ README.md
├─ changelog.md
├─ CHANGELOG.md
├─ environment.yml
├─ pyproject.toml
├─ requirements-build.txt
Expand Down