On Tue, May 30, 2017 at 9:12 PM, Craig Ringer <cr...@2ndquadrant.com> wrote: > Thoughts? Backpatch new TAP methods, etc, into back branches routinely?
So, on the one hand, it is certainly useful to be able to commit tests to back-branches as well as to master, and it's hard to do that if the infrastructure isn't there. On the other hand, we tell our users that we only back-patch security and stability fixes. When customers start to doubt that, then they become reluctant to apply new minor versions in their entirety and ask for individual commits to be cherry-picked, or just don't upgrade at all. One could argue that commits to the testing framework shouldn't make customers nervous, but what people should be worried about and what they are actually worried about do not always match. It is useful to be able to show a customer a list of things that were done in a minor release and see nothing in there that can be described as optional tinkering. The TAP tests seem to be evolving incredibly quickly, with new infrastructure being built out all the time. That strengths both the argument for back-patching (to keep things in sync) and for not back-patching (to avoid churning a supposedly-stable branch). I'm not sure exactly what I think about this issue, but I'm very skeptical of the idea that back-patching less conservatively will have no downsides. -- 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