diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md
index 10e1a737f91b..5edf9a17005b 100644
--- a/.github/PULL_REQUEST_TEMPLATE.md
+++ b/.github/PULL_REQUEST_TEMPLATE.md
@@ -18,6 +18,10 @@ detail.  Why is this change required?  What problem does it solve?-->
 - [ ] Adds a test for any bugs fixed. Adds tests for new features.
 - [ ] Code is formatted
 - [ ] Changes are summarized in CHANGELOG.md
+- [ ] Change is breaking (API, behavior, ...)
+  - [ ] Change is *additionally* added to CHANGELOG.md in the breaking section
+  - [ ] PR is marked as breaking
+  - [ ] Short summary API changes at the top of the PR (plus optionally with an automated update/fix script)
 - [ ] CI has been triggered on [Darwin](https://re-git.lanl.gov/eap-oss/parthenon/-/pipelines) for performance regression tests.
 - [ ] Docs build
 - [ ] (@lanl.gov employees) Update copyright on changed files
diff --git a/CHANGELOG.md b/CHANGELOG.md
index 1365442a8764..9e8555710754 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -2,6 +2,22 @@
 
 ## Current develop
 
+### Added (new features/APIs/variables/...)
+
+### Changed (changing behavior/API/variables/...)
+
+### Fixed (not changing behavior/API/variables/...)
+
+### Infrastructure (changes irrelevant to downstream codes)
+
+### Removed (removing behavior/API/varaibles/...)
+
+### Incompatibilities (i.e. breaking changes)
+
+
+## Release 23.11
+Date: 2023-11-16
+
 ### Added (new features/APIs/variables/...)
 - [[PR 962]](https://github.com/parthenon-hpc-lab/parthenon/pull/962) Add support for in-situ histograms/profiles
 - [[PR 911]](https://github.com/parthenon-hpc-lab/parthenon/pull/911) Add infrastructure for geometric multi-grid
@@ -21,6 +37,7 @@
 - [[PR 868]](https://github.com/parthenon-hpc-lab/parthenon/pull/868) Add block-local face, edge, and nodal fields and allow for packing
 
 ### Changed (changing behavior/API/variables/...)
+- [[PR 977]](https://github.com/parthenon-hpc-lab/parthenon/pull/977) Change to CalVer from SemVer
 - [[PR 975]](https://github.com/parthenon-hpc-lab/parthenon/pull/975) Construct staged integrators via arbitrary name
 - [[PR 976]](https://github.com/parthenon-hpc-lab/parthenon/pull/976) Move UserWorkBeforeLoop to be after first output
 - [[PR 965]](https://github.com/parthenon-hpc-lab/parthenon/pull/965) Allow leading whitespace in input parameters
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 0685a11d14fb..994399d4bdc0 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -20,7 +20,7 @@ cmake_minimum_required(VERSION 3.16)
 # Imports machine-specific configuration
 include(cmake/MachineCfg.cmake)
 
-project(parthenon VERSION 0.8.0 LANGUAGES C CXX)
+project(parthenon VERSION 23.11 LANGUAGES C CXX)
 
 if (${CMAKE_VERSION} VERSION_GREATER_EQUAL 3.19.0)
   cmake_policy(SET CMP0110 NEW)
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index d1830c6f6d60..5f170d85b989 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -39,26 +39,20 @@ Use GitHub labels as appropriate and feel free to directly add/tag people to the
 
 ### Summary of Branching Model and Versioning
 
-Two main branches exist:
-- `stable` contains the latest "stable" release
-- `develop` contains all approved changes since the previous release
+Only a single main branch called `develop` exists and all PRs should be merged
+into that branch.
+Individual versions/releases are tracked by tags.
 
-We aim at creating a new release everyone 4 to 6 weeks.
+We aim at creating a new release every 6 months.
 The decision on creating a new release is made during the bi-weekly calls.
-A release consists of of merging `develop` into `stable` and create a new tag for that version
-using a modified [semantic versioning](https://semver.org/) scheme.
-Releases will be tagged `v0.MAJOR.MINOR` given the current rapid development.
-
-- MAJOR is incremented for API incompatible changes
-- MINOR is incremented for backwards compatible changes and bug fixes
-
-This scheme will be reevaluated once a future version is considered to be the first official stable release.
-
-The main idea behind separating `stable` from `develop` is to allow for more in-depth nightly testing
-on the latter.
-This specifically applies to downstream codes so that incompatibilities (e.g., due to to an
-updated API) are discovered early.
-
+Following steps need to be done for a new release:
+
+- Create a new tag for that version using a modified [calender versioning](https://calver.org/) scheme.
+Releases will be tagged `vYY.0M` i.e., short years and zero-padded months.
+- Update the version in the main `CMakeLists.txt`.
+- Update the `CHANGELOG.md` (i.e., add a release header and create new empty
+categories for the "Current develop" section.
+- Sent a mail to the mailing list announcing the new release.
 
 ### Contributing Code