Thread: 9.4RC1 next week
We need to get moving if we want to have RC1 out before the holiday season starts. Accordingly, the core committee has agreed that we should wrap it next week (usual timing: wrap Monday 17th for announcement Thursday 20th). According to https://wiki.postgresql.org/wiki/PostgreSQL_9.4_Open_Items the only open release-blocking issue is what are we going to do about the incorrect CRC calculation in logical-replication files. My own vote is to Just Fix It, but in any case we need to make a decision this week. regards, tom lane
Hi, On 2014-11-11 10:18:55 -0500, Tom Lane wrote: > We need to get moving if we want to have RC1 out before the holiday season > starts. Accordingly, the core committee has agreed that we should wrap it > next week (usual timing: wrap Monday 17th for announcement Thursday 20th). Ah cool. So there won't be a corresponding set of backbranch releases which will instead be done together with 9.4.0? > According to > https://wiki.postgresql.org/wiki/PostgreSQL_9.4_Open_Items > the only open release-blocking issue is what are we going to do about > the incorrect CRC calculation in logical-replication files. My own > vote is to Just Fix It, but in any case we need to make a decision > this week. I've a patch and will push it tomorrow. Greetings, Andres Freund
Andres Freund <andres@anarazel.de> writes:
> On 2014-11-11 10:18:55 -0500, Tom Lane wrote:
>> We need to get moving if we want to have RC1 out before the holiday season
>> starts. Accordingly, the core committee has agreed that we should wrap it
>> next week (usual timing: wrap Monday 17th for announcement Thursday 20th).
> Ah cool. So there won't be a corresponding set of backbranch releases
> which will instead be done together with 9.4.0?
No. I don't think we have our ducks in a row for back-branch updates just
yet. In any case, it would be good to get some real-world testing of
b2cbced9e before we unleash that on stable-branch users ;-)
BTW, we try to avoid doing back-branch updates at the exact same time as
a major .0 release anyway. In the first place, that confuses the PR
messaging: we'd rather it be all about the new release and not about bugs
fixed in old branches. In the second place, as an ex-packager I know that
there are usually some gotchas in packaging a new major release, so it's
better that packagers not have back-branch updates on their plates at the
same time.
regards, tom lane
On 2014-11-11 10:52:30 -0500, Tom Lane wrote: > Andres Freund <andres@anarazel.de> writes: > > On 2014-11-11 10:18:55 -0500, Tom Lane wrote: > >> We need to get moving if we want to have RC1 out before the holiday season > >> starts. Accordingly, the core committee has agreed that we should wrap it > >> next week (usual timing: wrap Monday 17th for announcement Thursday 20th). > > > Ah cool. So there won't be a corresponding set of backbranch releases > > which will instead be done together with 9.4.0? > > No. I don't think we have our ducks in a row for back-branch updates just > yet. Right. I'm mainly asking because there's some unlogged table crash recovery issues I want to get fixed before the next set of backbranch releases. It's also been a while since the last back branch release. Nothing egregiously bad, but a fair number of moderately annoying things. Apropos back branches: I think 52eed3d426 et al wasn't reverted and we didn't really agree on a solution? > In any case, it would be good to get some real-world testing of > b2cbced9e before we unleash that on stable-branch users ;-) Heh. > BTW, we try to avoid doing back-branch updates at the exact same time as > a major .0 release anyway. In the first place, that confuses the PR > messaging: we'd rather it be all about the new release and not about bugs > fixed in old branches. In the second place, as an ex-packager I know that > there are usually some gotchas in packaging a new major release, so it's > better that packagers not have back-branch updates on their plates at the > same time. Makes sense. Greetings, Andres Freund
Andres Freund <andres@anarazel.de> writes:
> Apropos back branches: I think 52eed3d426 et al wasn't reverted and we
> didn't really agree on a solution?
I think we agreed what we wanted to do instead, but actually doing it
is on my queue and hasn't reached the front yet. In any case, 52eed3d426
is better than no fix.
regards, tom lane