Skip to content

Automate post-release development bump #9

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
defunctl merged 1 commit into from
Jul 1, 2026
Merged

Automate post-release development bump #9

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
70 changes: 69 additions & 1 deletion .github/workflows/monorepo-split.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -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:
Expand Down Expand Up @@ -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
8 changes: 6 additions & 2 deletions AGENTS.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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 <constraint>` 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 <next-dev-constraint>` 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 <next-dev-constraint>`, `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.
11 changes: 7 additions & 4 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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 <constraint>` | 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 <next-dev-constraint>` 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 <release-constraint>`, 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 <next-dev-constraint>`, `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
Expand Down
Loading