From 87a3bc19635a37600d4a28d286441cc3a8fd380c Mon Sep 17 00:00:00 2001 From: Justin Frydman Date: Wed, 1 Jul 2026 15:01:13 -0600 Subject: [PATCH] Automate post-release development bump --- .github/workflows/monorepo-split.yml | 70 +++++++++++++++++++++++++++- AGENTS.md | 8 +++- README.md | 11 +++-- 3 files changed, 82 insertions(+), 7 deletions(-) diff --git a/.github/workflows/monorepo-split.yml b/.github/workflows/monorepo-split.yml index a28125e..9690897 100644 --- a/.github/workflows/monorepo-split.yml +++ b/.github/workflows/monorepo-split.yml @@ -1,4 +1,4 @@ -# Pushes releases out to stellarwp/prophecy-* git sub-repos. +# Pushes package code and release tags out to stellarwp/foundation-* split repositories. name: Split Monorepo Packages and Release on: @@ -66,3 +66,71 @@ jobs: # ↓ the user signed under the split commit user_name: "StellarWP GitHub Action" user_email: "action@github.com" + + bump-next-development-line: + needs: split + if: ${{ startsWith(github.ref, 'refs/tags/') }} + runs-on: ubuntu-latest + + steps: + - name: Determine next development line + id: version + shell: bash + run: | + tag="${GITHUB_REF_NAME}" + + if [[ ! "$tag" =~ ^([0-9]+)\.([0-9]+)\.0$ ]]; then + echo "Tag ${tag} is not a minor or major release tag ending in .0; skipping dev-main bump." + echo "should_bump=false" >> "$GITHUB_OUTPUT" + exit 0 + fi + + major="${BASH_REMATCH[1]}" + minor="${BASH_REMATCH[2]}" + next_minor=$((minor + 1)) + + echo "should_bump=true" >> "$GITHUB_OUTPUT" + echo "constraint=^${major}.${next_minor}" >> "$GITHUB_OUTPUT" + echo "alias=${major}.${next_minor}.x-dev" >> "$GITHUB_OUTPUT" + + - name: Checkout main + if: ${{ steps.version.outputs.should_bump == 'true' }} + uses: actions/checkout@v6 + with: + ref: main + token: ${{ secrets.GH_BOT_TOKEN }} + fetch-depth: 0 + + - name: Set up PHP + if: ${{ steps.version.outputs.should_bump == 'true' }} + uses: shivammathur/setup-php@v2 + with: + php-version: '8.3' + coverage: none + + - name: Install Composer dependencies + if: ${{ steps.version.outputs.should_bump == 'true' }} + uses: ramsey/composer-install@v4 + with: + dependency-versions: highest + + - name: Bump next development line + if: ${{ steps.version.outputs.should_bump == 'true' }} + run: | + composer monorepo bump-interdependency "${{ steps.version.outputs.constraint }}" + composer monorepo package-alias + composer monorepo merge + + - name: Commit next development line + if: ${{ steps.version.outputs.should_bump == 'true' }} + run: | + if git diff --quiet -- composer.json src/*/composer.json; then + echo "No next development line changes to commit." + exit 0 + fi + + git config user.name "StellarWP GitHub Action" + git config user.email "action@github.com" + git add composer.json src/*/composer.json + git commit -m "Bump Foundation to ${{ steps.version.outputs.alias }}" + git push origin HEAD:main diff --git a/AGENTS.md b/AGENTS.md index ffdb8b6..b07274f 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -163,5 +163,9 @@ After completing a feature, run `composer test:coverage`, review `clover.xml` fo - Adding a new split package is usually a minor SemVer release because it introduces new functionality without breaking existing packages. Use a major release only if the change also breaks an existing public API or package contract. - Run `composer monorepo bump-interdependency ` when planning a major version release so Foundation packages that depend on each other require the new major line, for example `^3.0`. It may also be useful for a minor release when one package must require APIs added in that new minor, for example `^1.1`. -- After publishing a minor or major release, fetch the new release tag and run `composer monorepo bump-interdependency ` and `composer monorepo package-alias` to move `dev-main` to the next development line, for example from `1.1.x-dev` to `1.2.x-dev`. Do not run this for every patch release when the current branch alias is still correct. -- The monorepo split workflow deploys package code to each sub-repository on pushes to `main` and when release tags are pushed. Publishing a GitHub release creates the release tag and triggers the tagged split. +- Before publishing a release, verify the intended release-line package constraints are already committed. For a minor release such as `1.2.0`, internal Foundation package dependencies should already require the released line, for example `^1.2`. +- Publishing a GitHub release creates the release tag and triggers the tagged monorepo split. Wait for the tagged `Split Monorepo Packages and Release` workflow to succeed before considering the release complete. +- After a successful tagged split for a minor or major `.0` release, the split workflow automatically bumps internal package constraints and branch aliases to the next development line on `main`, for example from `^1.2` and `1.2.x-dev` to `^1.3` and `1.3.x-dev`. +- The post-release automation intentionally skips patch tags such as `1.2.1`, because patch releases should not move `dev-main` to a new minor development line. +- If the post-release automation fails, fetch the release tag and manually run `composer monorepo bump-interdependency `, `composer monorepo package-alias`, and `composer monorepo merge`, then commit and push the updated package `composer.json` files. +- The monorepo split workflow deploys package code to each sub-repository on pushes to `main` and when release tags are pushed. diff --git a/README.md b/README.md index 198ad1c..3380a10 100644 --- a/README.md +++ b/README.md @@ -106,18 +106,21 @@ composer analyze ### 🥳 Releasing a new version -Before drafting the release, run the monorepo maintenance commands that apply to the release: +Before drafting the release, run only the monorepo maintenance commands that prepare the release line itself: | Situation | Command | Why | |-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| --- | --- | -| You are planning a major version release, for example `2.0` to `3.0`. You should run this so any Foundation packages that depend on each other require the new major line, such as `^3.0`. You may also run it for a minor release if one package must require APIs added in that new minor version. | `composer monorepo bump-interdependency ` | Updates package-to-package dependency constraints. Use the new minimum Composer constraint, such as `^3.0` or `^1.2`. | -| You have published a minor or major release and `dev-main` should move to the next development line. For example, after releasing `1.1.0`, update internal dependencies to `^1.2` and the branch alias from `1.1.x-dev` to `1.2.x-dev`. Do not run this before every patch release if the existing alias is still correct. | `git fetch --tags`, then `composer monorepo bump-interdependency ` and `composer monorepo package-alias` | Updates package-to-package dependency constraints for the next development line, then updates each package's `extra.branch-alias` using the latest local release tag and the format configured in `monorepo-builder.php`. | -| Neither of the above changed. | No monorepo maintenance command is needed. | Continue to drafting the release. | +| You are planning a major version release, for example `2.0` to `3.0`. You should run this so any Foundation packages that depend on each other require the new major line, such as `^3.0`. You may also run it for a minor release if one package must require APIs added in that new minor version. | `composer monorepo bump-interdependency `, then `composer monorepo merge` | Updates package-to-package dependency constraints for the release being published. Use the release's minimum Composer constraint, such as `^3.0` or `^1.2`. | +| Internal package constraints already match the release line. | No pre-release monorepo maintenance command is needed. | Continue to drafting the release. | After any needed command, commit the updated `composer.json` files. Then draft a new release on [GitHub](https://github.com/stellarwp/foundation/releases/new), following [semver](https://semver.org/) closely. The [monorepo split GitHub workflow](./.github/workflows/monorepo-split.yml) deploys each project's code to its sub-repository on pushes to `main` and when release tags are pushed. Publishing a GitHub release creates the release tag and triggers the tagged split. +After a successful tagged split for a minor or major `.0` release, the workflow automatically moves `dev-main` to the next development line. For example, publishing `1.2.0` causes the workflow to bump internal constraints to `^1.3` and branch aliases to `1.3.x-dev`. Patch releases such as `1.2.1` intentionally skip this step. + +If the automated post-release bump fails, fetch the release tag and manually run `composer monorepo bump-interdependency `, `composer monorepo package-alias`, and `composer monorepo merge`, then commit and push the updated package `composer.json` files. + Adding a new split package is usually a minor [semver](https://semver.org/) release because it adds new functionality without breaking existing packages. Use a major release only if the change also breaks an existing public API or package contract. ### Monorepo