Skip to content

Document release process and include actual release notes in Changelog file #94

Description

@weiji14

The release process doesn't appear to be documented very well (e.g. with a checklist). The past few release PRs did not have without any description (e.g. #68, #73, #76), and the changelog page at https://tudelftgeodesy.github.io/sarxarray/CHANGELOG/ simply points to https://github.com/TUDelftGeodesy/sarxarray/releases even though it states "All notable changes to this project will be documented in this file".

# Change Log
All notable changes to this project will be documented in this file.
This project adheres to [Semantic Versioning](http://semver.org/).
See [releases](https://github.com/TUDelftGeodesy/sarxarray/releases) in the sarxarray repository for more details.

Recommendations:

  1. Actually include release notes in CHANGELOG.md (refer to https://www.pyopensci.org/python-package-guide/documentation/repository-files/changelog-file.html on formatting)
  2. Create a checklist, possibly as an Issue/Pull Request template, so that maintainers know how to create a release. Include steps such as:

Note that these are only suggestions, and you're welcome to implement some or all of the above 🙂 There are also other 'advanced' methods of e.g. updating the version based on git tags (https://www.pyopensci.org/python-package-guide/package-structure-code/python-package-versions.html#tool-3-setuptools-scm-versioning-using-git-tags), but up to you on what you're comfortable with implementing.

Part of JOSS review at openjournals/joss-reviews#10492

Metadata

Metadata

Assignees

Type

No type

Fields

No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions