Re: Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0 - Mailing list pgsql-hackers
| From | David G. Johnston |
|---|---|
| Subject | Re: Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0 |
| Date | |
| Msg-id | CAKFQuwa8CpNTWTcrtue-Hyxv1Uyc6WU+3pRYe1nHHXkTmzMyvg@mail.gmail.com Whole thread Raw |
| In response to | Re: Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0 (Robert Haas <robertmhaas@gmail.com>) |
| List | pgsql-hackers |
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.
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.
pgsql-hackers by date: