Subject: [pgjdbc/pgjdbc] issue #3812: Release is releasing a SNAPSHOT version

From: "davecramer (@davecramer)" <[email-masked]>
Date: Thu, 18 Sep 2025 22:00:16 +0000

see $subject

---

From: "sehrope (@sehrope)" <[email-masked]>
Date: Fri, 19 Sep 2025 12:43:56 +0000

@vlsi What is the status of the release workflows? I see a 42.7.8 in central now, but the most recent workflow run shows failure. When it's all working, can we use it to release backpatched versions as well, e.g., a 42.2.x?

---

From: "vlsi (@vlsi)" <[email-masked]>
Date: Fri, 19 Sep 2025 12:54:26 +0000

>I see a 42.7.8 in central now, but the most recent workflow run shows failure.

Please check the reasons for the falure. I have fixed it already.

>can we use it to release backpatched versions as well, e.g., a 42.2.x?

Yeah, we should back-patch the release workflows as needed.

---

From: "sehrope (@sehrope)" <[email-masked]>
Date: Fri, 19 Sep 2025 13:04:37 +0000

I don't consider it fixed until I see a release done end-to-end without any manual intervention with the action successful. The CI shows failure so that clearly has not happened yet.

And it sounds like we either need to backpatch whatever was fixed to the older branches. Or update how things run so that it uses the latest version of the workflow in master but publishes from a version built from a separate branch. That feels like it'd have less maintenance in the future (only worry about keeping it in sync in master) but I'm not sure if we'd need any special handling for publishing back-patch releases.

Are you going to back patch the release fixes?

When this is all settled, I actually want to run the whole thing again end to end. We don't have to wait for any meaningful code changes. Version numbers are cheap so we can burn as many as we want to ensure this thing is working.

---

From: "vlsi (@vlsi)" <[email-masked]>
Date: Fri, 19 Sep 2025 13:47:09 +0000

Thanks, Sehrope!

I fully agree with you — the real goal here is to have a smooth, fully automated release that can run end-to-end without manual steps. The last run failed only due to a branch protection rule at the final stage; I’ve already adjusted the rule, so that specific problem won’t occur again in the next run.

That said, we did successfully roll out 42.7.8 to both Central and GitHub Releases, so from a user’s perspective the release is already out there. What’s still pending is updating [jdbc.postgresql.org](https://jdbc.postgresql.org/), otherwise users may get confused by the mismatch. I’d like to get that site updated before cutting the next release. Longer term, I think it would be great to automate the website deployment as part of the process.

On “back-patching”
The release workflow only exists on master right now, so there’s nothing to back-patch in older branches. We could certainly copy the workflow into older release branches if we want a consistent experience across them, but that’s a separate step from fixing the recent CI failure.

On burning versions
I’m fine with doing another end-to-end test release once the website is updated. We should just be mindful that every new tag triggers dependabot updates across a lot of projects, so it’s worth balancing the desire to test with the impact on downstream consumers.

So, in short:

* The branch-rule blocker is fixed.
* Next step: update jdbc.postgresql.org for 42.7.8.
* Then we can run the next release end-to-end with the updated workflow.

If you have extra issues, please feel free to open issues so we don't accidentally lose the items.