SPF-OST / pytrnsys

Package that provides functionality to run and process, plot and report TRNSYS simulations
https://pytrnsys.readthedocs.io
GNU General Public License v3.0
11 stars 8 forks source link

Release [version number here] (needs to be adapted for pytrnsys) #108

Open martin-neugebauer opened 2 years ago

martin-neugebauer commented 2 years ago

This issue is intended as a template. A "copy" should be made of this issue for each release. Unfortunately, GitHub doesn't support copying issues, hence you'll need to manually copy and paste this template's body and title text to a new issue for your release. In your copy, delete this boldface text. Now you're ready to go: good luck with the release!

Usage and definitions

Work through the check-boxed items one after the other.

Let y denote this release's version number and x denote the previous release's version number.

Preliminaries

Manual tests

Create release

  1. Change the version mentioned in the README.md's installation instructions to y.

  2. Commit and push your changes to README.md

  3. Create a new release on GitHub here: https://github.com/SPF-OST/pytrnsys_gui/releases/new. Follow the semantic versioning convention (or see "Semantic versioning for the impatient" below) when coming up with version numbers.

  4. Copy the directory requirements/releases/x (including its contained files) to requirements/releases/y

  5. Update requirements/releases/y: set the pytrnsys-gui version to y: pytrnsys-gui==y

  6. Run dev-tools/compileRequirementsTxts.py -P pytrnsys-gui

  7. Revert all changed requirements.txt and requirements.in files except the ones under requirements/releases/y.

  8. Compare the contents of requirements/releases/y/requirements.txt to requirements/releases/y/requirements.txt (only the version of pytrnsys-gui and any package whose version you've explicitely changed [or which you've added/ removed] should have changed)

  9. Add the files under requirements/releases/y to the repository, commit and push.

Test the released package

Semantic versioning for the impatient

Semantic versioning basically means (quoting from semver.org)

Given a version number MAJOR.MINOR.PATCH, increment the:

    1. MAJOR version when you make incompatible API changes,
    2. MINOR version when you add functionality in a backwards compatible manner, and
    3. PATCH version when you make backwards compatible bug fixes.