or a new page). Hence, in doubt, it is good resource to figure out if it is
end of road for that release.
[1]
https://www.timeanddate.com/countdown/generic?iso=20260406T12&p0=3926&msg=Feature+freeze&font=cursive&csz=1
[2] https://www.postgresql.org/developer/roadmap/
--
On Thu, Apr 10, 2025 at 03:11:00PM +0300, Heikki Linnakangas wrote:
> On 10/04/2025 14:57, Aleksander Alekseev wrote:
>> Do you think that it's worth merging SLRU refactoring into PG18, or is
>> it considered a feature? [1] This is arguably not the top priority and
>> we could wait for another year
Hi,
> > Do you think that it's worth merging SLRU refactoring into PG18, or is
> > it considered a feature? [1] This is arguably not the top priority and
> > we could wait for another year but merging it now doesn't seem to be
> > too much of a burden either.
> >
> > [1]: https://commitfest.postgr
On 10/04/2025 14:57, Aleksander Alekseev wrote:
Let me be the first author this year who asks to squeeze his patch in
after feature freeze :D
On that note, I spoke with Matthias off-list, and he pointed out this patch:
https://www.postgresql.org/message-id/CAEze2Wh9JjLKdN3dHPF%3DNejzf
https://wiki.postgresql.org/wiki/Release_Management_Team
>
> We have now entered the feature freeze period. That means that no new
> features will committed for v18 anymore. I ask everyone to focus on
> testing the new features that got in, documentation, and fixes for old
> and new bugs.
>
> You ca
On 10/04/2025 14:57, Aleksander Alekseev wrote:
Let me be the first author this year who asks to squeeze his patch in
after feature freeze :D
:-)
Do you think that it's worth merging SLRU refactoring into PG18, or is
it considered a feature? [1] This is arguably not the top priority a
On Tue, Apr 08, 2025 at 11:24:39AM -0500, Nathan Bossart wrote:
> I always forget if AoE is UTC+12 or UTC-12. [...]
One isn't supposed to think "is the freeze on everywhere", just "is the
freeze on for me" and "is the freeze on for this particular contribution
(check the date header)".
Nico
--
have now entered the feature freeze period. That means that no new
features will committed for v18 anymore. I ask everyone to focus on
testing the new features that got in, documentation, and fixes for old
and new bugs.
You can track open items for the PostgreSQL 18 release here:
On Tue, Apr 8, 2025 at 10:13 PM Daniel Gustafsson wrote:
>
> I find both of the above needlessly confusing when we instead could use UTC
> which is a more universally understood concept.
Indeed, that's what the "U" stands for, after all. :-)
--
John Naylor
Amazon Web Services
On Wed, 9 Apr 2025 at 03:54, Bruce Momjian wrote:
> We did have this discussion when AoE was chosen for PG 18 and the idea
> was that as long as it is before April 18 midnight wherever you are, it
> is not feature freeze yet.
I think it maybe once made sense for the moment to stop acce
On 2025-04-08 Tu 11:45 AM, Peter Geoghegan wrote:
On Tue, Apr 8, 2025 at 11:20 AM Nathan Bossart wrote:
+1 for UTC.
+1, I think that AoE is needlessly obscure
+1
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On Tue, Apr 08, 2025 at 05:13:15PM +0200, Daniel Gustafsson wrote:
>> On 8 Apr 2025, at 16:59, Bruce Momjian wrote:
>> Frankly, I think the name "anywhere on Earth" is confusing, since it
>> really is "everywhere on Earth":
>
> I find both of the above needlessly confusing when we instead could u
Ashutosh Bapat writes:
> Any timezone based deadline might be seen as unfair to those for whom
> that time falls in their respective nights. AoE removes that
> unfairness.
... only with an interpretation of AoE that is shared by nobody.
It's quite clear that everyone else on this thread reads the
On Tue, Apr 8, 2025 at 9:30 PM Peter Eisentraut wrote:
>
> On 08.04.25 16:59, Bruce Momjian wrote:
> > On Tue, Apr 8, 2025 at 10:36:45AM -0400, Bruce Momjian wrote:
> >> Since we recorded feature freeze as April 8, 2025 0:00 AoE (anywhere on
> >> Eart
On Tue, Apr 8, 2025 at 12:29 PM Andrew Dunstan wrote:
> The fact that there is this confusion is an indication that the AoE
> experiment is a failure. If it's not obvious, and people have to think
> about it, then it's not working. And I bet there is a huge number of
> people who have never even h
ng as it is before April 18 midnight wherever you are, it
is not feature freeze yet.
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
Do not let urgent matters crowd out time for investment in the future.
On 2025-04-08 Tu 12:11 PM, Bruce Momjian wrote:
On Tue, Apr 8, 2025 at 06:00:27PM +0200, Peter Eisentraut wrote:
On 08.04.25 16:59, Bruce Momjian wrote:
On Tue, Apr 8, 2025 at 10:36:45AM -0400, Bruce Momjian wrote:
Since we recorded feature freeze as April 8, 2025 0:00 AoE (anywhere on
On Tue, Apr 08, 2025 at 06:00:27PM +0200, Peter Eisentraut wrote:
> On 08.04.25 16:59, Bruce Momjian wrote:
>> Anywhere on Earth (AoE) is a calendar designation that indicates
>> that a period expires when the date passes everywhere on Earth.
>
> Yes, that works intuitively when you spec
On 08/04/2025 19:11, Bruce Momjian wrote:
On Tue, Apr 8, 2025 at 06:00:27PM +0200, Peter Eisentraut wrote:
On 08.04.25 16:59, Bruce Momjian wrote:
On Tue, Apr 8, 2025 at 10:36:45AM -0400, Bruce Momjian wrote:
Since we recorded feature freeze as April 8, 2025 0:00 AoE (anywhere on
Earth
On Tue, Apr 8, 2025 at 06:00:27PM +0200, Peter Eisentraut wrote:
> On 08.04.25 16:59, Bruce Momjian wrote:
> > On Tue, Apr 8, 2025 at 10:36:45AM -0400, Bruce Momjian wrote:
> > > Since we recorded feature freeze as April 8, 2025 0:00 AoE (anywhere on
> > > Earth):
On 4/8/25 11:20, Nathan Bossart wrote:
On Tue, Apr 08, 2025 at 05:13:15PM +0200, Daniel Gustafsson wrote:
On 8 Apr 2025, at 16:59, Bruce Momjian wrote:
Frankly, I think the name "anywhere on Earth" is confusing, since it
really is "everywhere on Earth":
I find both of the above needlessly con
On 08.04.25 16:59, Bruce Momjian wrote:
On Tue, Apr 8, 2025 at 10:36:45AM -0400, Bruce Momjian wrote:
Since we recorded feature freeze as April 8, 2025 0:00 AoE (anywhere on
Earth):
https://wiki.postgresql.org/wiki/PostgreSQL_18_Open_Items#Important_Dates
https
On Tue, Apr 8, 2025 at 11:20 AM Nathan Bossart wrote:
> +1 for UTC.
+1, I think that AoE is needlessly obscure
--
Peter Geoghegan
> On 8 Apr 2025, at 16:59, Bruce Momjian wrote:
>
> On Tue, Apr 8, 2025 at 10:36:45AM -0400, Bruce Momjian wrote:
>> Since we recorded feature freeze as April 8, 2025 0:00 AoE (anywhere on
>> Earth):
>>
>> https://wiki.postgresql.org/wiki/PostgreSQL_18_Op
Daniel Gustafsson writes:
> On 8 Apr 2025, at 16:59, Bruce Momjian wrote:
>> Frankly, I think the name "anywhere on Earth" is confusing, since it
>> really is "everywhere on Earth":
> I find both of the above needlessly confusing when we instead could use UTC
> which is a more universally unders
On Tue, Apr 8, 2025 at 10:36:45AM -0400, Bruce Momjian wrote:
> Since we recorded feature freeze as April 8, 2025 0:00 AoE (anywhere on
> Earth):
>
>
> https://wiki.postgresql.org/wiki/PostgreSQL_18_Open_Items#Important_Dates
> https://www.timeanddate.com/time/zon
Since we recorded feature freeze as April 8, 2025 0:00 AoE (anywhere on
Earth):
https://wiki.postgresql.org/wiki/PostgreSQL_18_Open_Items#Important_Dates
https://www.timeanddate.com/time/zones/aoe
and it is now 2:34 AM AoE, I guess we are now in feature freeze.
--
Bruce
On Mon, 8 Apr 2024 at 16:26, Robert Haas wrote:
> And maybe we need to think of a way to further mitigate this crush of
> last minute commits. e.g. In the last week, you can't have more
> feature commits, or more lines of insertions in your commits, than you
> did in the prior 3 weeks combined. I
On Tue, Apr 9, 2024 at 5:16 PM Bruce Momjian wrote:
> Committing code is a hard job, no question. However, committers have to
> give up the idea that they should wait for brilliant ideas before
> finalizing patches. If you come up with a better idea later, great, but
> don't wait to finalize pat
ically was one of the driving factors in why we started doing
> commitfests in the first place (you should have seen the mad dash of
> commits before we had that process), so ISTM that it's not completely
> avoidable...
>
> That said, are you suggesting that the feature freeze d
On Mon, Apr 8, 2024 at 09:32:14PM +0200, Jelte Fennema-Nio wrote:
> I'll sketch a situation: There's a big patch that some non-committer
> submitted that has been sitting on the mailinglist for 6 months or
> more, only being reviewed by other non-committers, which the submitter
> quickly addresses
On 2024-04-08 Mo 19:26, Tom Lane wrote:
Andrew Dunstan writes:
I quite like the triage idea. But I think there's also a case for being
more a bit more flexible with those patches we don't throw out. A case
close to my heart: I'd have been very sad if the NESTED piece of
JSON_TABLE hadn't made
tains more than just "last minute crushes" [^1]. I don't think we
> should throw out the baby with the bathwater here.
>
>> A complex patch needs to be
>> submitted early in the cycle, not in the last CF. If it's submitted
>> early, but does not rece
interest/reviews, I think we need to
> fix & improve that - not to rework/push it at the very end.
Agree on all this, too.
-Matthias
[^0] (see e.g. the EXPLAIN SERIALIZE patch thread [0], where the
original author did not have the time capacity to maintain the
patchset over months:
https
Andrew Dunstan writes:
> I quite like the triage idea. But I think there's also a case for being
> more a bit more flexible with those patches we don't throw out. A case
> close to my heart: I'd have been very sad if the NESTED piece of
> JSON_TABLE hadn't made the cut, which it did with a few
On 2024-04-08 Mo 12:07, Alvaro Herrera wrote:
On 2024-Apr-08, Robert Haas wrote:
And maybe we need to think of a way to further mitigate this crush of
last minute commits. e.g. In the last week, you can't have more
feature commits, or more lines of insertions in your commits, than you
did in
On 4/8/24 21:32, Jelte Fennema-Nio wrote:
> On Mon, 8 Apr 2024 at 20:15, Tomas Vondra
> wrote:
>> I 100% understand how frustrating the lack of progress can be, and I
>> agree we need to do better. I tried to move a number of stuck patches
>> this CF, and I hope (and plan) to do more of this i
On Mon, Apr 8, 2024 at 3:32 PM Jelte Fennema-Nio wrote:
> Maybe a better solution to this problem would be to spread impactful
> reviews by committers more evenly throughout the year. Then there
> wouldn't be such a rush to address them in the last commit fest.
Spreading activity of all sorts mor
On Mon, 8 Apr 2024 at 20:15, Tomas Vondra wrote:
> I 100% understand how frustrating the lack of progress can be, and I
> agree we need to do better. I tried to move a number of stuck patches
> this CF, and I hope (and plan) to do more of this in the future.
>
> But I don't quite see how would thi
ybe there is a hybrid model
where they exists in pull requests, tested through CfBot, and merged
when ready - no matter what month it is.
Pull requests could still have labels that ties them to a "CommitFest"
to "high-light" them, but it would make it easier to have a much cleare
On 4/8/24 17:48, Matthias van de Meent wrote:
> On Mon, 8 Apr 2024 at 17:21, Tomas Vondra
> wrote:
>>
>> ...
>>
>> For me the main problem with the pre-freeze crush is that it leaves
>> pretty much no practical chance to do meaningful review/testing, and
>> some of the patches likely went throu
mitigating the
last-minute rush, it might also be a good idea to consider how to
improve testing the new commits during beta. FWIW in each year, after
feature freeze I personally pick some new features that I didn't get
involved with during the development and do intensive reviews in
April. It
On 2024-Apr-08, Robert Haas wrote:
> And maybe we need to think of a way to further mitigate this crush of
> last minute commits. e.g. In the last week, you can't have more
> feature commits, or more lines of insertions in your commits, than you
> did in the prior 3 weeks combined. I don't know. I
e.
I don't want more barriers to getting stuff committed here either, but
I also don't want somebody whose 100-line patch is basically unchanged
since last July to commit it 19 hours before the feature freeze
deadline[1]. That's just making everyone's life more difficult. If
t
ays in, and I do 100% agree we should maintain the high commit bar we
have and not rush things in just so "they're in for feature freeze and
we'll clean them up for beta." That's where best practices come in.
I tend to judge the release by the outcome: once we go GA
[ shrug... ] There were fifty-some commits on the last day,
> > > some of them quite large, and you want me to finger particular ones?
> > > I can't even have read them all yet.
> > >
> > >> Yeah, I should have done that sooner, but realistically, there's
> nothi
gt;
> >> Yeah, I should have done that sooner, but realistically, there's nothing
> >> like a looming deadline as a motivator. One idea to avoid the mad rush
> >> in the future would be to make the feature freeze deadline more
> >> progressive. Fo
Hi,
On 2024-04-08 09:26:09 -0400, Robert Haas wrote:
> On Sun, Apr 7, 2024 at 6:50 PM Michael Paquier wrote:
> And maybe we need to think of a way to further mitigate this crush of
> last minute commits. e.g. In the last week, you can't have more
> feature commits, or more lines of insertions in
On 4/8/24 11:05, Tom Lane wrote:
Pavel Borisov writes:
IMO the fact that people struggle to work on patches, and make them better,
etc. is an immense blessing for the Postgres community. Is the peak of
commits really a big problem provided we have 6 months before actual
release? I doubt March p
ere were fifty-some commits on the last day,
> some of them quite large, and you want me to finger particular ones?
> I can't even have read them all yet.
>
>> Yeah, I should have done that sooner, but realistically, there's nothing
>> like a looming deadline as a mo
Pavel Borisov writes:
> IMO the fact that people struggle to work on patches, and make them better,
> etc. is an immense blessing for the Postgres community. Is the peak of
> commits really a big problem provided we have 6 months before actual
> release? I doubt March patches tend to be worse than
me to finger particular ones?
I can't even have read them all yet.
> Yeah, I should have done that sooner, but realistically, there's nothing
> like a looming deadline as a motivator. One idea to avoid the mad rush
> in the future would be to make the feature freeze deadline
gs
> come first. The resulting code changes look the same they have for a
> long time, and I didn't uncover any significant new issues while doing
> that. I would not have felt comfortable committing it otherwise.
>
> Yeah, I should have done that sooner, but realistically, t
as of the moment of typing this email, I get:
> > > > =# select '2024-04-08 00:00-12:00' - now() as time_remaining;
> > > > time_remaining
> > > > -
> > > > 13:10:35.688134
> > > > (1 row)
> > > >
&
, there's nothing
like a looming deadline as a motivator. One idea to avoid the mad rush
in the future would be to make the feature freeze deadline more
progressive. For example:
April 1: If you are still working on a feature that you still want to
commit, you must explicitly flag it in the c
> On 8 Apr 2024, at 17:26, Melanie Plageman wrote:
>
> What if we pick the actual feature freeze time randomly? That is,
> starting on March 15th (or whenever but more than a week before), each
> night someone from RMT generates a random number between $current_day
> and
On Mon, 2024-04-08 at 09:26 -0400, Robert Haas wrote:
> And maybe we need to think of a way to further mitigate this crush of
> last minute commits. e.g. In the last week, you can't have more
> feature commits, or more lines of insertions in your commits, than you
> did in the prior 3 weeks combine
12:00' - now() as time_remaining;
> > > time_remaining
> > > -
> > > 13:10:35.688134
> > > (1 row)
> > >
> > > So there is just a bit more than half a day remaining before the
> > > feature freeze is in effect.
; -
> > 13:10:35.688134
> > (1 row)
> >
> > So there is just a bit more than half a day remaining before the
> > feature freeze is in effect.
>
> OK, so feature freeze is now in effect, then.
>
> In the future, let's use GMT for these deadl
Robert Haas writes:
> And maybe we need to think of a way to further mitigate this crush of
> last minute commits. e.g. In the last week, you can't have more
> feature commits, or more lines of insertions in your commits, than you
> did in the prior 3 weeks combined. I don't know. I think this mad
bit more than half a day remaining before the
> feature freeze is in effect.
OK, so feature freeze is now in effect, then.
In the future, let's use GMT for these deadlines. There have got to be
a lot more people who can easily understand when a certain GMT
timestamp falls in their local tim
now() as time_remaining;
time_remaining
-
13:10:35.688134
(1 row)
So there is just a bit more than half a day remaining before the
feature freeze is in effect.
--
Michael
signature.asc
Description: PGP signature
On Mon, 18 Mar 2024 at 15:50, Michael Paquier wrote:
> Additionally, the RMT has set the feature freeze to be **April 8, 2024
> at 0:00 AoE** (see [1]). This is the last time to commit features for
> PostgreSQL 17. In other words, no new PostgreSQL 17 feature can be
> committed a
On Mon, Mar 18, 2024 at 12:39 PM Hayato Kuroda (Fujitsu)
wrote:
>
> > If you think that this is OK, and as far as I can see this looks OK on
> > the thread, then this open item should be moved under "resolved before
> > 17beta1", mentioning the commit involved in the fix. Please see [1]
> > for e
Dear Michael,
> If you think that this is OK, and as far as I can see this looks OK on
> the thread, then this open item should be moved under "resolved before
> 17beta1", mentioning the commit involved in the fix. Please see [1]
> for examples.
OK, I understood that I could wait checking from y
On Mon, Mar 18, 2024 at 03:49:24AM +, Hayato Kuroda (Fujitsu) wrote:
> I think the entry can be closed:
>
> ```
> pg_upgrade with --link mode failing upgrade of publishers
> Commit: 29d0a77fa660
> Owner: Amit Kapila
> ```
>
> The reported failure was only related with the test script, not the
Dear Michael,
> We are pleased to announce the Release Management Team (RMT) (cc'd)
> for the PostgreSQL 17 release:
> - Robert Haas
> - Heikki Linnakangas
> - Michael Paquier
Thanks for managing the release of PostgreSQL to proceed the right direction!
> You can track open items for the Postgre
nally, the RMT has set the feature freeze to be **April 8, 2024
at 0:00 AoE** (see [1]). This is the last time to commit features for
PostgreSQL 17. In other words, no new PostgreSQL 17 feature can be
committed after April 8, 2024 at 0:00 AoE. As mentioned last year in
[2], this uses the &quo
On 4/6/23 5:37 PM, Jonathan S. Katz wrote:
On 3/21/23 11:35 AM, Jonathan S. Katz wrote:
Additionally, the RMT has set the feature freeze to be **April 8, 2023
at 0:00 AoE**[1]. This is the last time to commit features for
PostgreSQL 16. In other words, no new PostgreSQL 16 feature can be
On 3/21/23 11:35 AM, Jonathan S. Katz wrote:
Additionally, the RMT has set the feature freeze to be **April 8, 2023
at 0:00 AoE**[1]. This is the last time to commit features for
PostgreSQL 16. In other words, no new PostgreSQL 16 feature can be
committed after April 8, 2023 at 0:00 AoE
On 3/21/23 1:17 PM, Roberto Mello wrote:
On Tue, Mar 21, 2023 at 9:35 AM Jonathan S. Katz wrote:
You can track open items for the PostgreSQL 16 release here:
https://wiki.postgresql.org/wiki/PostgreSQL_16_Open_Items
The wiki page references April 8th, 2022, btw.
Fixed :) Thanks!
Jon
On Tue, Mar 21, 2023 at 9:35 AM Jonathan S. Katz wrote:
>
> You can track open items for the PostgreSQL 16 release here:
>
> https://wiki.postgresql.org/wiki/PostgreSQL_16_Open_Items
The wiki page references April 8th, 2022, btw.
Roberto
_Team
Additionally, the RMT has set the feature freeze to be **April 8, 2023
at 0:00 AoE**[1]. This is the last time to commit features for
PostgreSQL 16. In other words, no new PostgreSQL 16 feature can be
committed after April 8, 2023 at 0:00 AoE.
You can track open items for the PostgreSQL 16 re
On 3/26/22 11:10 AM, Jonathan S. Katz wrote:
Additionally, the RMT has set the feature freeze date to be April 7,
2022. This is the last day to commit features for PostgreSQL 15. In
other words, no new PostgreSQL 15 feature can be committed after April 8
0:00, 2022 AoE[1].
[1] https
_Team
Additionally, the RMT has set the feature freeze date to be April 7,
2022. This is the last day to commit features for PostgreSQL 15. In
other words, no new PostgreSQL 15 feature can be committed after April 8
0:00, 2022 AoE[1].
You can track open items for the PostgreSQL 15 release here:
On Mon, Mar 22, 2021 at 10:17:56AM +0900, Michael Paquier wrote:
> The Release Management Team (RMT) for the PostgreSQL 14 is assembled
> and has determined that the feature freeze date for the PostgreSQL 11
> release will be April 7, 2021. This means that any feature for the
> P
Hi,
The Release Management Team (RMT) for the PostgreSQL 14 is assembled
and has determined that the feature freeze date for the PostgreSQL 11
release will be April 7, 2021. This means that any feature for the
PostgreSQL 14 release *must be committed by April 7, 2021 AoE*
("anywhere on
On 3/30/20 10:18 AM, Jonathan S. Katz wrote:
> Hi,
>
> The Release Management Team (RMT) for the PostgreSQL 13 is assembled and
> has determined that the feature freeze date for the PostgreSQL 11
> release will be April 7, 2020. This means that any feature for the
> PostgreSQL
Hi,
The Release Management Team (RMT) for the PostgreSQL 13 is assembled and
has determined that the feature freeze date for the PostgreSQL 11
release will be April 7, 2020. This means that any feature for the
PostgreSQL 13 release **must be committed by April 7, 2020 AOE**
("anywhere on
On Sat, Mar 30, 2019 at 06:40:43PM +0900, Michael Paquier wrote:
> The Release Management Team (RMT) for the PostgreSQL 12 release
> has been assembled and has determined that the feature freeze date
> for the PostgreSQL 12 release will be April 7, 2019. This means that
> any feature
Hi,
The Release Management Team (RMT) for the PostgreSQL 12 release
has been assembled and has determined that the feature freeze date
for the PostgreSQL 12 release will be April 7, 2019. This means that
any feature that will be going into the PostgreSQL 12 release must be
committed before 2019
On Fri, Apr 6, 2018 at 6:59 PM, Jonathan S. Katz wrote:
> Best of luck to everyone over the next 24hrs!
I think that's the wrong sentiment, honestly. I think we have too
many committers relying way too much on luck already.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterpris
mail.gmail.com
>
> I think my confusion resulted from the fact that my 2016 message said
> "must be committed no later than XXX" whereas yours says that the
> feature freeze date is XXX.
>
> But no worries - thanks for clarifying.
Noted for next year.
Best of luck to everyone over the next 24hrs!
Jonathan
sage said
"must be committed no later than XXX" whereas yours says that the
feature freeze date is XXX.
But no worries - thanks for clarifying.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Apr 6, 2018, at 6:53 PM, Robert Haas wrote:
>
> On Tue, Mar 27, 2018 at 9:51 AM, Jonathan S. Katz
> wrote:
>> The Release Management Team (RMT) for the PostgreSQL 11 release
>> has been assembled and has determined that the feature freeze date
>> for the
On Tue, Mar 27, 2018 at 9:51 AM, Jonathan S. Katz wrote:
> The Release Management Team (RMT) for the PostgreSQL 11 release
> has been assembled and has determined that the feature freeze date
> for the PostgreSQL 11 release will be April 7, 2018. This means that any
> feature that w
Hi,
The Release Management Team (RMT) for the PostgreSQL 11 release
has been assembled and has determined that the feature freeze date
for the PostgreSQL 11 release will be April 7, 2018. This means that any
feature that will be going into the PostgreSQL 11 release must be
committed before 2018
87 matches
Mail list logo
