On Sun, Aug 7, 2016 at 4:09 PM, Greg Sabino Mullane <greg@turnstep.com> wrote:
> Robert Haas wrote:
>> But I'm neither willing to commit a patch to fix the day before rc1
>> nor to argue that the whole release cycle should be put back by
>> several weeks on account of this issue.
>
> Seriously? First, not sure why this would put the whole release cycle
> back by 'several weeks'.
It's a combination of three things. First, it is unhelpful to users
and to the project and burdensome to packagers to do lots of releases
in quick succession. If we issue beta4 this week, we should really
wait about 3 weeks before we consider issuing beta5 or rc1.
Otherwise, we're going to have little time to get any meaningful
feedback on the release, and possibly annoy some of our all-volunteer
packaging team. Second, we are doing a set of minor releases this
week and those minor releases will include some security fixes. We do
not want to do minor releases for the back branches without releasing
a new version of 9.6, because that leaves people who are trying to
help with beta-testing for 9.6 running close with disclosed security
vulnerabilities. Third, I don't think it's appropriate to have a
catversion bump between rc1 and final; rc1 should be very, very close
to final; if it's not, we weren't really ready for rc1.
Because of point #2, we have to release either 9.6beta4 or 9.6rc1 this
week. If we pick 9.6rc1, then because of point #3, we cannot make
this change before final. If we pick 9.6beta4, then because of point
#1, we cannot reasonably release 9.6rc1 for about another 3 weeks.
These issues have been discussed by the release team, which includes
the core team and the pool of active committers, and this is the
consensus. Of course, you may not agree.
> Second, this is removing functionality, so what
> are apps supposed to do - have a three-choice case in the code to handle
> pg_am for < 9.6, do some ugly parsing for 9.6, and use the new functions
> when 10.0 comes out?! This issue was raised on July 25th, and the OP has
> gone out of his way to present the case and provide patches. It's hardly
> fair to discard it now.
I understand your concern and I wish things had come out differently
than they have with respect to this issue. However, I do not agree
that rushing a patch into the tree less than 24 hours before rc1 is
likely to improve our chances of a stable, on-time release, and I also
do not agree that this one issue is so important that it justifies
holding up the final release by another three weeks. You may feel
differently and that is fine, but I do not think that my position is
unreasonable.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
