Skip to content

RELEASE.md

Latest commit

 

History

History
34 lines (25 loc) · 3.26 KB

RELEASE.md

File metadata and controls

34 lines (25 loc) · 3.26 KB
Raw

Releasing MappingWeaver

Step-by-step instructions for publishing a release. HANDBOOK.md (Release process) explains how the tooling works.

Before you start

  • Everything changed since the previous release is reviewed: the code for correctness, and the documentation and changelog for accuracy and brevity.
  • bash (Git Bash on Windows), Maven, Java 21, and changefrog (npm install -g changefrog), which writes the version section of CHANGELOG.md.
  • Push access to origin (https://gitlab.ilabt.imec.be/rml/proc/mappingweaver-java).
  • You are on development, up to date with origin/development, with a clean working tree.
  • The tests pass: mvn verify.
  • The conformance run meets conformance/expected-results.csv: start the manual Conformance job in the latest development pipeline, or run conformance/run.sh (HANDBOOK: Conformance). A case that passes now is removed from the file, with its line in the changelog.
  • ## Unreleased states the conformance change since the previous release: git diff v<previous> -- conformance/expected-results.csv lists it, a removed line being a case that passes now and an added line one that no longer does.
  • ## Unreleased in CHANGELOG.md lists everything since the last release.
  • Pick the version with Semantic Versioning. pom.xml holds the next patch as -SNAPSHOT (<version>-SNAPSHOT): release that patch, or a higher minor or major version when the changelog has new features or breaking changes.

Release

  1. Run ./bump-version.sh <version> (format X.Y.Z) and answer y to both questions. The script
    • sets the version in pom.xml and the jar name in README.md;
    • turns ## Unreleased into the version section of CHANGELOG.md;
    • commits "Update version to ", pushes development, and creates and pushes the tag v<version>;
    • moves pom.xml to the next patch -SNAPSHOT, and commits and pushes "Prepare for next development cycle".
  2. Move main to the release: git push origin v<version>^{commit}:main. main always points at the latest release; the push succeeds only as a fast-forward.
  3. The tag pipeline (https://gitlab.ilabt.imec.be/rml/proc/mappingweaver-java/-/pipelines) builds the release with the release Maven profile, signs it and deploys it to Maven Central. The new version then appears at https://repo1.maven.org/maven2/be/ugent/idlab/knows/MappingWeaver/ (this can take up to an hour). The pipeline's Package job also keeps the runnable jar as a job artifact.

After the release

When something goes wrong

  • The script stops at the first failing command. When it stops before pushing, fix the cause, discard its changes (git reset --hard origin/development) and run it again. When it stops after pushing development, finish by hand: create the tag v<version> on the version commit if it is missing, push it (git push origin v<version>), then set the next -SNAPSHOT (mvn versions:set -DnewVersion=<next>-SNAPSHOT -DgenerateBackupPoms=false), commit and push.
  • Once the tag is pushed, keep it: fix the cause and retry the failed pipeline job. When the released code itself is broken, release the next patch version.