Re: proposal for a new minor release schedule

Hi,

On Sat, 5 Sept 2026 at 00:58, Nathan Bossart <nathandbossart(at)gmail(dot)com> 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(at)(dot)]
>
> 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