Hi, On Sat, 5 Sept 2026 at 00:58, Nathan Bossart <[email protected]> wrote: > > [This idea has been discussed on security@, pgsql-release@, and > pgsql-packagers@ a bit already. The purpose of this thread is to gather > feedback from the community at large, in preparation for a final vote from > the members of pgsql-release@.] > > Given the recent influx of bug reports, I am proposing that we release > minor versions of PostgreSQL more frequently. The hope is that releasing > more often will get fixes in users' hands faster, and that we can be more > disciplined about whether to include something in a given release. This > might also help reduce the number of judgment calls about whether an > out-of-cycle release is needed. Previous discussions have revealed > widespread, but not unanimous, support for this idea. The trade-offs > include additional release work and extra restarts for users. Nobody thus > far has indicated those are dealbreakers, but it'd be good to get more > feedback.
+1 for the proposal. Getting security and crash fixes into users' hands sooner seems worth the additional release work and occasional extra restarts. > From my reading, the following three concrete proposals would reach the > ballot, but other ideas are still welcome: > > * Second Thursday of every even-numbered month (e.g., Feb, April, June). > This would result in 2 extra releases per year, for a total of 6 releases > each year. > > * Second Thursday of every odd-numbered month (e.g., Jan, March, May). As > above, this adds 2 releases per year. > > * Existing quarterly schedule, with releases inserted approximately halfway > between the existing minor releases. This would likely mean a release > every 6-7 weeks, and would result in 4 extra releases per year, for a > total of 8 releases each year. I would prefer releases in odd-numbered months, if only to avoid a December release. In my experience, December is when users are least likely to schedule upgrades or restarts. > Another topic of discussion has been whether to consider this a trial run > or a permanent change. My interpretation is that there's a general > preference for testing the new schedule for a while to see how it goes. > Since v19 is running a bit behind this year, I personally think it would be > best if we started the new schedule in 2027. Later in the year, we could > decide whether to make the change permanent or to revert back to quarterly. > > Thoughts? I also agree that starting the new schedule in 2027 makes sense. [If we plan on implementing the changes] Regards, Ayush
