From 137dc17679e50ee6aec03fb8abadb9c77741e990 Mon Sep 17 00:00:00 2001 From: Gerasimos Chourdakis Date: Fri, 6 Dec 2024 08:56:23 +0100 Subject: [PATCH 1/3] Document release schedule As decided in the coding days, Stuttgart, November 2024 --- pages/docs/dev-docs/release-strategy.md | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/pages/docs/dev-docs/release-strategy.md b/pages/docs/dev-docs/release-strategy.md index 7c058b9813..c2928b4862 100644 --- a/pages/docs/dev-docs/release-strategy.md +++ b/pages/docs/dev-docs/release-strategy.md @@ -38,6 +38,19 @@ permalink: dev-docs-release-strategy.html 5. Make sure everything is working 6. Release R +## Release schedule + +The core library repository follows semantic versioning. + +We group together breaking changes and release a new breaking version as needed, but not more frequently than once every two years (aiming for longer). This aims to give time and motivation to users to adopt new versions, and spreads the effort of preparing a release over a longer period of time. There is no fixed schedule for major releases, and we take time to ensure that no further breaking changes are needed soon after. + +We aim for feature releases twice per year, so that new features can be continuously shipped to new users, but we again don't get overly burdened by the release process, and feature releases maintain their significance. We define a feature freeze date (date after which no new feature contributions can be merged) and a release date (date of merging to the main branch and tagging the release). Since most of the development happens in universities, we align these dates with the lecture-free periods between semesters in these universities: + +- spring release: feature freeze on March 20 at 23:59 CET, release as soon as possible in April +- fall release: feature freeze on September 20 at 23:59 CET, release as soon as possible in October + +Bugfix releases are allowed at any time and any frequency. + ## Umbrella / distribution - twice per year, following the preCICE feature releases. From b76bc60b268bbb5d18ad366497590bd6fc42ab11 Mon Sep 17 00:00:00 2001 From: Gerasimos Chourdakis Date: Mon, 9 Dec 2024 12:06:17 +0100 Subject: [PATCH 2/3] Clearly mention release branch --- pages/docs/dev-docs/release-strategy.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pages/docs/dev-docs/release-strategy.md b/pages/docs/dev-docs/release-strategy.md index c2928b4862..2083c50856 100644 --- a/pages/docs/dev-docs/release-strategy.md +++ b/pages/docs/dev-docs/release-strategy.md @@ -44,7 +44,7 @@ The core library repository follows semantic versioning. We group together breaking changes and release a new breaking version as needed, but not more frequently than once every two years (aiming for longer). This aims to give time and motivation to users to adopt new versions, and spreads the effort of preparing a release over a longer period of time. There is no fixed schedule for major releases, and we take time to ensure that no further breaking changes are needed soon after. -We aim for feature releases twice per year, so that new features can be continuously shipped to new users, but we again don't get overly burdened by the release process, and feature releases maintain their significance. We define a feature freeze date (date after which no new feature contributions can be merged) and a release date (date of merging to the main branch and tagging the release). Since most of the development happens in universities, we align these dates with the lecture-free periods between semesters in these universities: +We aim for feature releases twice per year, so that new features can be continuously shipped to new users, but we again don't get overly burdened by the release process, and feature releases maintain their significance. We define a feature freeze date (date after which no new feature contributions can be merged to the release branch) and a release date (date of merging the release branch to the main branch and tagging the release). Since most of the development happens in universities, we align these dates with the lecture-free periods between semesters in these universities: - spring release: feature freeze on March 20 at 23:59 CET, release as soon as possible in April - fall release: feature freeze on September 20 at 23:59 CET, release as soon as possible in October From 03c6e36816917e0fa2ed524a6a8bbb88355d325a Mon Sep 17 00:00:00 2001 From: Gerasimos Chourdakis Date: Tue, 10 Dec 2024 18:23:49 +0100 Subject: [PATCH 3/3] Update pages/docs/dev-docs/release-strategy.md --- pages/docs/dev-docs/release-strategy.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pages/docs/dev-docs/release-strategy.md b/pages/docs/dev-docs/release-strategy.md index 2083c50856..8cfa5e050b 100644 --- a/pages/docs/dev-docs/release-strategy.md +++ b/pages/docs/dev-docs/release-strategy.md @@ -42,7 +42,7 @@ permalink: dev-docs-release-strategy.html The core library repository follows semantic versioning. -We group together breaking changes and release a new breaking version as needed, but not more frequently than once every two years (aiming for longer). This aims to give time and motivation to users to adopt new versions, and spreads the effort of preparing a release over a longer period of time. There is no fixed schedule for major releases, and we take time to ensure that no further breaking changes are needed soon after. +We group together breaking changes and release a new breaking (major) version as needed. There is no fixed schedule for major releases, and we take time to ensure that no further breaking changes are needed soon after. This aims to give time and motivation to users to adopt new versions, and spreads the effort of preparing a release over a longer period of time. We aim for feature releases twice per year, so that new features can be continuously shipped to new users, but we again don't get overly burdened by the release process, and feature releases maintain their significance. We define a feature freeze date (date after which no new feature contributions can be merged to the release branch) and a release date (date of merging the release branch to the main branch and tagging the release). Since most of the development happens in universities, we align these dates with the lecture-free periods between semesters in these universities: