TAP backpatching policy

From: Craig Ringer <craig(at)2ndquadrant(dot)com>
To: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: TAP backpatching policy
Date: 2017-05-31 01:12:46
Message-ID: CAMsr+YFx8V73k5DR_Lgn+q7CTAfzSj90q92VOGGV7qohNBybUA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi all

I propose that we backpatch all practical TAP enhancements back to the
last supported back branch.

At the moment that'd be 9.5, since that's where PostgresNode was
introduced. But if I can find the time I'd quite like to backport
PostgresNode to 9.4 too.

Where needed, PostgresNode could have version-dependent logic so we
could just copy the Perl module to the different branches.

This would make it much easier to test for bugs when doing work on
back branches, run the same test on multiple branches, etc. My
personal motivation is mainly using it in extensions, but I've
_frequently_ found myself writing TAP tests when looking into possible
Pg bugs etc too. Not having the same facilities in the different
branches makes this way harder.

If combined with pg_config --version-num (which IMO deserves a
backpatch especially now Pg 10 makes parsing our versions harder) this
would make it a lot more practical to do nontrivial tests in
extensions - which really matters since we introduced bgworkers.

Thoughts? Backpatch new TAP methods, etc, into back branches routinely?

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Craig Ringer 2017-05-31 01:14:20 pg_config --version-num
Previous Message Robert Haas 2017-05-31 00:59:13 Re: [JDBC] Channel binding support for SCRAM-SHA-256