Release process
Use YYYY.MM.X for the release version and vYYYY.MM.X for its Git tag and Docker image.
A major release has X equal to 0.
1. Update Sirius Web
When the release requires a newer Sirius Web version, run the update script from the repository root on a branch with a clean working tree:
node ./scripts/update-sirius-web.js YYYY.MM.X
Use the Sirius Web version for YYYY.MM.X.
The script updates sirius.web.version in pom.xml, installs the matching @eclipse-sirius frontend packages in frontend/syson and frontend/syson-components, stages all changes, and creates a signed-off [releng] Switch to Sirius Web YYYY.MM.X commit.
Keep the Sirius Web bump in this dedicated commit, separate from the [releng] Bump version to YYYY.MM.X release commit.
Update the CHANGELOG.adoc file with the Sirius Web version.
Update the doc/content/modules/developer-guide/pages/release-process.adoc file if the Sirius Web update requires changes to the release process.
Review the dependency and lockfile changes, test SysON locally, and open a pull request for the update.
2. Prepare the release pull request
-
For a major release only, update
syson-tagindoc/content/antora.ymland the image version in the repository’sdocker-compose.ymltovYYYY.MM.0. -
Set
@eclipse-syson/syson-componentsinfrontend/syson/package.jsontoYYYY.MM.X. -
Run the release script from the repository root. The script updates project versions and creates the
[releng] Bump version to YYYY.MM.Xcommit:node ./scripts/prepare-release.js YYYY.MM.X -
Update
doc/content/modules/installation-guide/pages/migration-process.adocif the release needs migration instructions. -
If the Sirius Web or SysON REST APIs changed, run SysON locally, copy the JSON from
http://localhost:8080/v3/api-docs/rest-apis, and updatedoc/content/modules/developer-guide/assets/attachments/sirius-web-openapi.json. -
Stage any changes made after the script, including
docker-compose.yml, amend the bump commit, and open a pull request. -
Review the pull request against a previous release pull request. Check
package-lock.jsoncarefully; if it contains unexpected changes, deletepackage-lock.jsonand allnode_modulesdirectories, runnpm installagain, and amend the pull request. -
Run SysON locally and verify that it works.
-
Merge the pull request.
3. Tag the release
After the pull request is merged, create and push an annotated tag from main:
git switch main
git pull
git tag -a vYYYY.MM.X -m "vYYYY.MM.X"
git push origin vYYYY.MM.X
4. Prepare the next major release
For major releases only, merge the cooldown branch into main if it already contains the preparation commit.
Otherwise, create a [releng] Prepare next release commit with these changes:
-
Add a section for the next release to
CHANGELOG.adoc. -
Create the next release notes file in
doc/content/modules/user-manual/pages/release-notes/and include it fromrelease-notes.adocin the same directory, using the existing file naming convention, such as2026.11.0.adoc. -
Add a section for the next release to
doc/content/modules/installation-guide/pages/migration-process.adoc. -
Set
site.start_pageindoc/docs-site/antora-playbook.ymlto the major release just published, such asv2026.9.0@syson::index.adoc.
Verify all four changes after merging cooldown or the preparation commit.