Update RELEASE_PROCEDURE.md for Patch Release

.github/ISSUE_TEMPLATE/issue_template_release.md

@@ -0,0 +1,29 @@
+---
+name: Release Issue
+about: For new ideas, developments and features
+title: Release - Minor Version - 0.1.0
+labels: "enhancement"
+assignees: 'Ludee'
+
+---
+
+## Description of the release
+
+Describe the release in as much detail as possible. 
+
+## Details of the release
+
+**Name:** Find an appropriate and memorable name for the release that will help it be remembered.
+**Git tag:** v0.1.0 "super-repo Minor Release v0.1.0"
+**Release Manager:** Choose a responsible person.
+**Date:** Arrange a convenient date
+
+## Workflow checklist
+- I am aware of the workflow in RELEASE_PROCEDURE.md
+- Draft GitHub Release
+- Release Branch
+- Update the version files (CHANGELOG.md, CITATION.cff, setup.py)
+- Release Pull Request
+- Git Tag
+- GitHub Release
+- Set up new development

.github/pull_request_template.md

@@ -7,7 +7,7 @@ Describe the findings of the discussion in the issue or meeting.
 ### Added
 - Add a new class [(#)](https://github.com/rl-institut/super-repo/pull/)
 
-### Updated
+### Changed
 - Update a definition [(#)](https://github.com/rl-institut/super-repo/pull/)
 
 ### Removed

CHANGELOG.md

@@ -1,21 +1,22 @@
 # Changelog
 
-All notable changes to this project will be documented in this file.
+All notable changes to this project will be documented in this file. <br>
+For each version, important additions, changes and removals are listed here.
 
 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).
 
-Template:
-```
-## [0.0.0] - Release - Name of Release - 20YY-MM-DD
+
+## [Unreleased]
 
 ### Added
-- [(#)]()
+- Add issue template for release `issue_template_release.md` [(#43)](https://github.com/rl-institut/super-repo/pull/43)
+
 ### Changed
-- [(#)]()
+- Update the release procedure [(#43)](https://github.com/rl-institut/super-repo/pull/43)
+
 ### Removed
 - [(#)]()
-```
 
 
 ## [0.1.0] Minor Release - Emmy Hennings Day - 2023-08-10

RELEASE_PROCEDURE.md

@@ -17,59 +17,70 @@ The data follows the [Calendar Versioning (CalVer)](https://calver.org/).<br>
 It always has the format `YYYY-MM-DD`, e.g. `2022-05-16`.
 
 
-## GitHub and PyPI Release
+## GitHub Release
 
-### 1. 🐙 Create a `GitHub Issue`
-* Named `Release Patch v0.11.7`
-* Use `📝ISSUE_TEMPLATE_RELEASE` (❗ToDo❗)
-* Discuss a good and suitable name of the release
-* Define a day for the release
+Following the Semantic Versioning, different workflows for Major, Minor, or Patch
+releases are possible. <br>
+For Major and Minor releases, follow the complete workflow.<br>
+For a Patch release (Hotfix), start at [section 4](https://github.com/rl-institut/super-repo/blob/production/RELEASE_PROCEDURE.md#4--create-a-draft-github-release).
 
-▶️ This issue documents the status of the release!
-
-### 2. 🐙 Create a `GitHub Project`
+### 1. 🐙 Create a `GitHub Project`
 * Create [New classic project](https://github.com/rl-institut/super-repo/projects?type=classic)
 * Use the project template *Automated kanban with reviews*
-* Named `Release v0.11.7`
+* Named `super-repo-v0.1.0`
 * Add a meaningful description
 * Track project progress
 
-▶️ It gives an overview of open and finished issues and pull requests!
+▶️ It gives an overview of open and finished issues and Pull Requests!
+
+### 2. 🐙 Create a `GitHub Issue`
+* Use `📝issue_template_release`
+* Name `Release - Minor Version - 0.1.0`
+* Complete the necessary details
+
+▶️ This issue documents the status of the release!
+
+### 3. 🐙 Finish all planned Developments
+* Some days before the release, inform all developers
+* Merge the open Pull Requests
+* On release day, start the release early to ensure sufficient time for reviews
+* Merge everything on the `develop` branch
+
+▶️ Completion of the preparation of the planned release!
 
-### 3. 🐙 Create a `Draft GitHub Release`
+### 4. 🐙 Create a `Draft GitHub Release`
+* Start here for a **Patch Release** (Hotfix)
 * [Draft a new release](https://github.com/rl-institut/super-repo/releases/new)
-* Enter the release version number `v0.11.7` as title
-* Summarize key changes in the description
-    * `## [v0.11.7] Patch - Name - Date`
+* Enter the release version number `0.1.0` as title
+* Summarize key changes from changelog in the description
+    * `## [0.11.7] Minor Release - Name - Date`
     * `### Added`
     * `### Changed`
     * `### Removed`
-* Add a link to compare versions
-    * `**Compare versions:** [v0.11.6 - v0.11.7](https://github.com/rl-institut/super-repo/compare/v0.11.6...v0.11.7)`
 * Add a link to the `📝CHANGELOG.md`
     * `Also see [**CHANGELOG.md**](https://github.com/rl-institut/super-repo/blob/production/CHANGELOG.md)`
-* Save draft
-
-### 4. 🐙 Finish all planned Developments
-* Some days before the release, inform all developers
-* Merge the open pull requests
-* On release day, start the release early to ensure sufficient time for reviews
-* Merge everything on the `develop` branch
+* Add a link to compare versions
+    * `**Compare versions:** [0.1.0 - 0.2.0](https://github.com/rl-institut/super-repo/compare/v0.1.0...v0.2.0)`
+* **Save draft**
 
 ### 5. 💠 Create a `release` branch
-* Checkout `develop` and branch with `git checkout -b release-v0.11.7`
-* Push branch with `git push --set-upstream origin release-v0.11.7`
+* Checkout `develop` and branch with `git checkout -b release-v0.1.0`
+* Push branch with `git push --set-upstream origin release-v0.1.0`
+* Add bump2version (❗ToDo❗) 
 
 ### 6. 📝 Update the version files
 * `📝CHANGELOG.md`
-    * All Pull Request are included
-    * Add a new section with correct version number
-    * Give the suitable name to the release
+    * Check that all Pull Request are included
+    * Rename `Unreleased` section with release title from issue
+    * Follow `[0.0.0] Minor Release - Name of Release - 20YY-MM-DD`
 * `📝CITATION.cff`
-    * Update the version number
+    * Update `version`
+    * Update `date-released`
 * `📝setup.py`
     * Update `version`
-    * Update `download_url` (.../v0.11.7.tar.gz)
+    * Update `download_url` (.../v0.1.0.tar.gz)
+
+▶️ Increase version numbers!
 
 ### 7. 🐙 Create a `Release Pull Request`
 * Use `📝PR_TEMPLATE_RELEASE` (❗ToDo❗)
@@ -78,19 +89,64 @@ It always has the format `YYYY-MM-DD`, e.g. `2022-05-16`.
 * Run all test
 * Execute the software locally
 * Wait for reviews and tests
-* Merge PR but do not delete `release` branch
+* Merge Pull Request and delete `release` branch
+
+▶️ Merge code on `production` branch!
 
 ### 8. 💠 Set the `Git Tag`
 * Checkout `production` branch and pull
 * Check existing tags `git tag -n`
-* Create new tag: `git tag -a v0.11.7 -m "super-repo Patch Release v0.11.7 with PyPI"`
+* Create new tag: `git tag -a v0.1.0 -m "super-repo Minor Release v0.1.0"`
 * This commit will be the final version for the release, breath three times and check again
 * Push tag: `git push --tags`
+
 * If you messed up, remove tags and start again
-    * Delete local tag: `git tag -d v0.11.7`
-    * Delete remote tag: `git push --delete origin v0.11.7`
+    * Delete local tag: `git tag -d v0.1.0`
+    * Delete remote tag: `git push --delete origin v0.1.0`
 
-### 9. 💻 Create and publish package on PyPI
+▶️ Git Tag for GitHub Release!
+
+### 9. 🐙 Publish `GitHub Release`
+* Navigate to releases and open the draft release
+* Choose the correct `Git Tag`
+* Choose the `production` branch
+* Select `Set as the latest release`
+* Select `Create a discussion for this release` in category `Announcements`
+* **Publish release**
+
+▶️ Release on GitHub! 🚀
+
+### 10. 🐙 Set up new development
+* Create a Pull Request from `production` to `develop`
+* Create a new **Unreleased** section in the `📝CHANGELOG.md`
+```
+## [Unreleased]
+
+### Added
+- [(#)]()
+
+### Changed
+- [(#)]()
+
+### Removed
+- [(#)]()
+```
+
+▶️ Continue the developments 🛠
+
+
+## PyPi Release
+
+### 0. 💻 Check release on Test-PyPI
+* Check if the release it correctly displayed on [Test-PyPI](https://test.pypi.org/project/open-mastr/#history)
+* With each push to the release branch or the branch `test-release` the package is released on [Test-PyPI](https://test.pypi.org/project/open-mastr/#history) by GitHub workflow (test-pypi-publish.yml).
+  * Note: Pre-releases on Test-PyPI are only shown under `Release history` in the navigation bar.
+  * Note: The branch status can only be released to a version on Test-PyPI once. Thus, for every branch status that you want to see on Test-PyPI increment the build version with `bump2version build` and push afterwards.
+* Once testing on Test-PyPI is done, change the release version to the final desired version with `bump2version release`
+  * Note: The release on Test-PyPI might fail, but it will be the correct release version for the PyPI server.
+* Push commits to the `release-*` branch
+
+### 1. 💻 Create and publish package on PyPI
 * Navigate to git folder `cd D:\git\github\GROUP\REPO\`
 * Create package using `python setup.py sdist`
 * Check that file has been created in folder `dist`
@@ -102,21 +158,5 @@ It always has the format `YYYY-MM-DD`, e.g. `2022-05-16`.
 
 ▶️ Publish the Package
 
-### 10. 🐙 Publish `GitHub Release`
-* Summarize key changes in the description
-* Choose the correct git `tag`
-* Choose the `production` branch
-* Publish release
-
-▶️ Release on GitHub!
-
-### 11. 🐙 Set up new development
-* Create a Pull request from `production` to `develop`
-* Delete the `release` branch
-* Create a new **unreleased section** in the `📝CHANGELOG.md`
-
-▶️ Continue the developments 🛠
-
-
 ## Sources:
 * https://raw.githubusercontent.com/folio-org/stripes/master/doc/release-procedure.md

mkdocs.yml

@@ -39,7 +39,7 @@ theme:
 markdown_extensions:
   - admonition
   - toc:
-      permalink: 💙
+      permalink: "#"
   - pymdownx.superfences
   - pymdownx.highlight:
       use_pygments: true