On Tue, Apr 12, 2016 at 4:32 PM, David G. Johnston
<david.g.johnston@gmail.com> wrote:
> I give a solid +10 to Robert's opinions on the matter and aside from
> figuring out if and how to fit first-number versioning dynamics into our
> release policies I think the community is doing a sufficient job on the
> communication and planning front. The biggest resource need is quality
> control. I dislike the fact that we are currently in a situation where the
> first 3 point releases each year are considered "live betas" based
> especially on both 9.3 and 9.5 post-release significant bug counts.
/me blinks.
I find it shocking that you would compare 9.5 to 9.3 that way. Yeah,
we've had a few bugs in 9.5: in particular, it was disappointing to
have to disable abbreviated keys. But I'm not sure that I really
believe that affected massive numbers of users in a really negative
way - many locales were just fine, and not every locale that had a
problem with some string data necessarily had a problem with the
strings people were actually storing. But we haven't eaten anybody's
data, at least not beyond what can be fixed by a REINDEX, unless I
missed something here.
The fact is that this is a fairly hard problem to solve. Some bugs
are not going to get found before people try the software, and we
can't make them try it while it's in beta. We can only do our best to
do good code review, but inevitably we will miss some things.
As for your proposal that we blindly consider $(N+1).0 to follow $N.4,
I'm not particularly enthralled with that. I think it's a good idea
to look for a release that's got some particularly nifty feature(s)
and use that as the time to move the first digit. And, sure, plan to
have that happen every 4-6 years or so, but adjust based on what
actually gets into which releases.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company