Switch back to Github Flow because of Lerna limitations

CONTRIBUTING.md

@@ -103,19 +103,9 @@ Log4brains follows a **simplified Git Flow** model. Here’s how the process wor
    npm install log4brains@beta
    ```
 
-   This helps us get feedback from early adopters before merging changes into `stable`, and thus triggering a stable release.
+   This helps us get feedback from early adopters before triggering a stable release.
 
-7. **Releasing to Stable**: Once the `develop` branch is stable and tested, the maintainers will merge it into `stable`, and run manually `scripts/release.sh` + `make -C docker release version-tag branch-tag latest-tag` to publish a new stable release to npm (TODO: should be automated in the future).
-
-### Urgent hotfix specific case
-
-In the rare case that an urgent hotfix is needed on the current stable version while not wanting to release the `develop` branch yet, you can follow this process:
-
-1. Create a new branch from `stable` (instead of `develop`)
-2. Develop and test
-3. Submit a Pull Request to `stable` (instead of `develop`)
-4. A maintainer will review, merge and release the patch
-5. Then the maintainer will merge `stable` into `develop` to ensure the hotfix is ported to the beta version
+7. **Stable Release**: Once the `develop` branch is stable and tested, the maintainers will manually run `scripts/release.sh` + `make -C docker release version-tag branch-tag latest-tag` to publish a new stable release to npm (TODO: should be automated in the future).
 
 ## License
 
@@ -128,7 +118,7 @@ As discussed in [discussion #108](https://github.com/thomvaill/log4brains/discus
 To make it easier I introduce two co-maintainer roles:
 
 - **Canary Maintainers**: in charge of triaging issues, reviewing PRs, and can merge them into `develop` (and thus trigger a beta release)
-- **Core Maintainers**: in charge of the project's overall direction and vision, of releasing stable versions, and can merge `develop` into `stable` (and thus trigger a stable release)
+- **Core Maintainers**: in charge of the project's overall direction and vision, and of releasing stable versions
 
 If you're interested in becoming a co-maintainer, you can start your "Mentorship Phase" by participating in code reviews and helping triage issues. This will help us assess your familiarity with the project and the workflow.
 

docs/adr/20240926-transition-to-simplified-git-flow.md

@@ -1,6 +1,6 @@
 # Transition to Simplified Git Flow
 
-- Status: draft
+- Status: superseded by [20241217-switch-back-to-github-flow](20241217-switch-back-to-github-flow.md)
 - Date: 2024-09-26
 
 ## Context and Problem Statement

docs/adr/20241217-switch-back-to-github-flow.md

@@ -0,0 +1,31 @@
+# Switch back to GitHub Flow, but keeping the automated beta releases
+
+- Status: accepted
+- Date: 2024-12-17
+
+## Context and Problem Statement
+
+The previous decision to adopt a Simplified Git Flow with a `develop` and `stable` branch aimed to provide clearer separation between development and releases while enabling automated beta releases. However, we faced tooling limitations.
+
+Specifically, **Lerna**, which we use for managing our monorepo, does not integrate well with Git Flow processes ([Lerna issue #2023](https://github.com/lerna/lerna/issues/2023#issuecomment-480402592)), when managing both a `develop` and `stable` branches: we cannot make Lerna publish a stable release from a different branch than the main one.
+
+## Decision Drivers <!-- optional -->
+
+- Make Lerna work again for stable releases
+- Keep the benefits of the previous workflow:
+  - Need for automation in releases.
+  - Be able to merge more quickly whithout breaking the stable branch, while making it possible for beta testers to test the new features.
+  - Easier delegation to new maintainers.
+  - Simplified yet structured process for contributors.
+  - Clearer separation between ongoing development and stable releases.
+
+## Considered Options
+
+- Option 1: Patch Lerna to keep the Simplified Git Flow (as described in the link above)
+- Option 2: Switch back to Github Flow, but keeping the automated beta releases
+
+## Decision Outcome
+
+Chosen option: "Option 2: Switch back to Github Flow, but keeping the automated beta releases", because it fullfils all the requirements.
+In fact, we can still merge quickly pull requests without releasing a stable release, while keeping the automated beta release.
+The stable release is a manual script executed by maintainers.

scripts/release.sh

@@ -17,9 +17,9 @@ npm config set registry https://registry.npmjs.org/
 
 cd "${ROOT_PATH}"
 
-if [[ "$(git rev-parse --abbrev-ref HEAD)" != "stable" ]]
+if [[ "$(git rev-parse --abbrev-ref HEAD)" != "develop" ]]
 then
-  echo "Please run this command from the stable branch"
+  echo "Please run this command from the develop branch"
   exit 1
 fi