pgjdbc/pgjdbc GitHub issues and pull requests (mirror)help / color / mirror / Atom feed
[pgjdbc/pgjdbc] issue #3812: Release is releasing a SNAPSHOT version 5+ messages / 3 participants [nested] [flat]
* [pgjdbc/pgjdbc] issue #3812: Release is releasing a SNAPSHOT version @ 2025-09-18 22:00 "davecramer (@davecramer)" <[email protected]> 0 siblings, 0 replies; 5+ messages in thread From: davecramer (@davecramer) @ 2025-09-18 22:00 UTC (permalink / raw) To: pgjdbc/pgjdbc <[email protected]> see $subject ^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: [pgjdbc/pgjdbc] issue #3812: Release is releasing a SNAPSHOT version @ 2025-09-19 12:43 "sehrope (@sehrope)" <[email protected]> 3 siblings, 0 replies; 5+ messages in thread From: sehrope (@sehrope) @ 2025-09-19 12:43 UTC (permalink / raw) To: pgjdbc/pgjdbc <[email protected]> @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? ^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: [pgjdbc/pgjdbc] issue #3812: Release is releasing a SNAPSHOT version @ 2025-09-19 12:54 "vlsi (@vlsi)" <[email protected]> 3 siblings, 0 replies; 5+ messages in thread From: vlsi (@vlsi) @ 2025-09-19 12:54 UTC (permalink / raw) To: pgjdbc/pgjdbc <[email protected]> >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. ^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: [pgjdbc/pgjdbc] issue #3812: Release is releasing a SNAPSHOT version @ 2025-09-19 13:04 "sehrope (@sehrope)" <[email protected]> 3 siblings, 0 replies; 5+ messages in thread From: sehrope (@sehrope) @ 2025-09-19 13:04 UTC (permalink / raw) To: pgjdbc/pgjdbc <[email protected]> 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. ^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: [pgjdbc/pgjdbc] issue #3812: Release is releasing a SNAPSHOT version @ 2025-09-19 13:47 "vlsi (@vlsi)" <[email protected]> 3 siblings, 0 replies; 5+ messages in thread From: vlsi (@vlsi) @ 2025-09-19 13:47 UTC (permalink / raw) To: pgjdbc/pgjdbc <[email protected]> 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. ^ permalink raw reply [nested|flat] 5+ messages in thread
end of thread, other threads:[~2025-09-19 13:47 UTC | newest] Thread overview: 5+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2025-09-18 22:00 [pgjdbc/pgjdbc] issue #3812: Release is releasing a SNAPSHOT version "davecramer (@davecramer)" <[email protected]> 2025-09-19 12:43 ` "sehrope (@sehrope)" <[email protected]> 2025-09-19 12:54 ` "vlsi (@vlsi)" <[email protected]> 2025-09-19 13:04 ` "sehrope (@sehrope)" <[email protected]> 2025-09-19 13:47 ` "vlsi (@vlsi)" <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox