Re: Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

On Tue, Apr 12, 2016 at 2:04 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Tue, Apr 12, 2016 at 4:32 PM, David G. Johnston
> <david(dot)g(dot)johnston(at)gmail(dot)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.
>

​I probably over-implied my feelings regarding 9.5 since, yes, abbreviated
keys was largely out of realm of reasonable expectation.
​

​I think I am colored by my involvement in attempting to help research this
one:​

9.5.1 ​"Fix an oversight that caused hash joins to miss joining to some
tuples of the inner relation in rare cases (Tomas Vondra, Tom Lane)"

This one struck me as well for some reason...

9.5.1 "Fix overeager pushdown of HAVING clauses when grouping sets are
used."

The two ROW() comparison fixes for 9.5.2

I'm not exactly someone looking to poke a stick in PostgreSQL's side so
regardless of degree of "validity" of my feelings that fact that I have
them is likely informative. Or I'm just in a particularly overly-sensitive
mood right now - I wouldn't fully discount the possibility.

> 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.
>

​Agreed, and to the point of using corporate resources for improvement of
existing work as opposed to roadmap stuff.​

> 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.
>
>
​The main point on that post was we emphasize not only the new stuff in the
just released version but that we re-celebrate everything that has been
accomplished in the previous​ 4 releases as well. If the first-digit is
getting such significant attention we might as well play to that fact and
try and remind people who've missed out on prior releases that we are
continually innovating. That, and the fact that the last N.0 release that
was so highly touted just went out of support.

Otherwise I don't see why we don't just start increment the first-digit
yearly. Sure, every so often we think we've done enough to warrant an
increase there but the philosophy as a community doesn't actually match our
particular choice - we don't, in advance, place any special importance on
the first-digit releases, as evidenced by this discussion.

David J.