The release process is now driven by GitHub Releases:
Caution
In general datafaker releases should increment the minor portion of the semver, in 2.x.y the x should be incremented.
- Go to the Releases page of the repository
- Click on "Draft a new release"
- Create a new tag in the format
x.y.z(semverMAJOR.MINOR.PATCH; e.g.2.7.1for a 2.x patch - Set the release title (can be the same as the tag)
- Add a description of the changes (optional - will be enhanced by automated changelog)
- Click "Publish release"
The automated workflow will then:
- Extract the version from the tag
- Update the Maven project version
- Build and deploy to Maven Central
- Generate a changelog and add it to the release notes
Followed by a separate job which will:
- Create a PR to update the pom.xml to the next SNAPSHOT version
- Update documentation:
- At least files
docs/releases/current.version.mddocs/releases/next.version-SNAPSHOT.md(repo only; excluded from the docs site)mkdocs.yml(see alsomaterial/README.mdfor docs site / theme dependency updates)docs/documentation/providers.md
- At least files
Snapshot release notes (docs/releases/{version}-SNAPSHOT.md) are optional draft pads between releases: excluded from the site and not linked in the Releases nav. The post-release workflow deletes docs/releases/{released}-SNAPSHOT.md when that version ships, then creates a fresh docs/releases/{next}-SNAPSHOT.md from the template. Stable releases appear at the top of the nav; older releases roll into {major}.x sections (e.g. 3.x, 2.x).
- The tag must follow semver format:
x.y.z(where x, y, and z are numeric) - GitHub Release creation permissions are required to trigger the workflow
- All required secrets must be configured in the repository settings
After publishing a release:
- Check the workflow run in the Actions tab
- Verify the artifact is published to Maven Central
- Review the PR created to update the SNAPSHOT version