On Tue, May 30, 2017 at 9:12 PM, Craig Ringer <craig@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
