Repository navigation
Modify release logic #1
Description
Modify the release logic so that instead of triggering from github releases, it triggers from a manual dispatch for the github action workflow.
Upon dispatch the workflow should get the current data in YYYY-MM-DD format (it's YYYY = years, MM = month, DD = day) and uses it to push a new tag and github release with the same name. If there are multiple releases in the same day, it should append a counter as suffix.
eg. in a single day
- first release is: 2026-09-19
- second release is : 2026-09-19-2
- third release is: 2026-09-19-3
the next day the counter will reset from zero eg. - first release is: 2026-09-20
- second release is : 2026-09-20-2
and so on...
After the tag and github release are ready, the workflow will build and push the artifacts to maven central using the same YYYY-MM-DD value as version (remove the previous v* logic).
Maven central snapshots follow the same logic, but are triggered by commits
Metadata
Metadata
Assignees
Labels
No labels
Activity
Release from workflow dispatch with date based versions
jaime-jmebot commentedon Sep 21, 2026
Implemented in #2. Summary of what the release logic looks like now:
Manual dispatch instead of GitHub releases. The
Release to Maven Centralworkflow is now triggered withworkflow_dispatch. On dispatch it computes the version, pushes the tag, creates the GitHub release with the same name, and only then publishes to Maven Central with-PtestdataVersion=<version>. The old tag/v*logic is gone.Versions. A new helper,
scripts/next-version.sh, returns the current day asYYYY-MM-DDand adds a counter when releases already exist for that day, using the highest existing counter plus one:2026-09-192026-09-19-22026-09-19-32026-09-20The counter is read from the git tags of the checkout, resets each day, and ignores legacy
v*tags.scripts/next-version-test.shcovers the counter, the daily reset and the odd inputs, and runs as part of the verify workflow.Snapshots. A new
Publish snapshot to Maven Centralworkflow publishesorg.jmonkeyengine:jme3-testdata:<YYYY-MM-DD>-SNAPSHOTon every commit tomaster. Same date value, no tag or GitHub release, and no counter, since a snapshot can be republished on the same version.Two small choices worth confirming: snapshots trigger on
masteronly (no counter, so every commit of the day republishes the same snapshot version), and concurrent release dispatches are serialized so two runs can't pick the same version. Happy to adjust either.