9.4RC1 next week

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers