chore: reset release-please state and force 1.0.64 cut#313
Conversation
1.0.63 and 1.0.64 were minted outside Release Please, leaving the manifest pinned at 1.0.62 and 1.0.64 missing from Maven Central. This: - Resets manifest to 1.0.63 (the last version actually on Maven Central). - Enables skip-snapshot so RP won't open a SNAPSHOT maintenance PR before the release PR (aligns Java with go-sdk/node-sdk/python-sdk). - Uses Release-As to force the next cut to 1.0.64, matching the already-bumped pom.xml, instead of the 1.1.0 a feat: commit would otherwise trigger. Release-As: 1.0.64
|
🐕 Review complete — View session on Shuni Portal 🐾 |
![shuni-bot-dev[bot]](https://avatars.githubusercontent.com/u/97479186?s=60&v=4){kind=small}
There was a problem hiding this comment.
🐕 Shuni's Review
Resets the release-please manifest to 1.0.63 (last version on Maven Central) and adds skip-snapshot: true to avoid the SNAPSHOT PR cycle, unblocking the 1.0.64 release via Release-As footer.
No issues found — good bones! Both JSON files are valid, the manifest version is correct, and skip-snapshot aligns with other Descope SDK repos. Woof!
There was a problem hiding this comment.
Pull request overview
Resets Release Please state to align the repo’s release automation with the last version confirmed to be published to Maven Central, and adjusts Release Please behavior to avoid creating intermediate SNAPSHOT PRs for this Maven project.
Changes:
- Updates
.release-please-manifest.jsonto reflect1.0.63as the current released version. - Updates
release-please-config.jsonto setskip-snapshot: truefor the root package.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
release-please-config.json |
Adds skip-snapshot: true under the root package configuration to avoid SNAPSHOT PRs. |
.release-please-manifest.json |
Moves the manifest version from 1.0.62 to 1.0.63 to re-anchor Release Please state. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Why
1.0.63 and 1.0.64 were minted outside Release Please (manual tag + GH Release, plus silent
pom.xmlbumps hidden in feature PRs #307 and #310). The manifest is still pinned at1.0.62, the PR #306 that added RP also deleted the oldon: release: [created]publish.yaml, and Slavik's manual1.0.64GH Release created yesterday never triggered a Maven Central publish.Net result:
1.0.64exists in git but is 404 on Maven Central, blocking GFM.What this PR does
.release-please-manifest.json→1.0.63(the last version actually on Maven Central).release-please-config.json→ adds"skip-snapshot": true. Prevents RP's Maven two-phase cycle from opening a SNAPSHOT PR (like chore(main): release java-sdk 1.0.63-SNAPSHOT #308, now closed) before the release PR. Aligns with howgo-sdk,node-sdk, andpython-sdkoperate.What happens after merge
The
Release-As: 1.0.64footer in this PR's squash commit message overrides conventional-commit bump rules (afeat:commit after the 1.0.63 tag would otherwise push us to 1.1.0). Release Please will open a release PR titled "chore(main): release java-sdk 1.0.64". Merging that release PR will:1.0.64+ GitHub Release1.0.64publishjob (release_created == true)mvn -B deploy -P ci→ Maven Central gets1.0.64→ GFM unblockedGoing forward
<version>inpom.xmlby hand — RP owns it.feat:/fix:/perf:/deps:) so RP classifies them.Merge instructions
When merging this PR, verify the squash commit message retains the
Release-As: 1.0.64footer below — without it, RP will propose1.1.0instead of1.0.64.Release-As: 1.0.64