On Sun, Aug 7, 2016 at 4:09 PM, Greg Sabino Mullane <g...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
