[HACKERS] TAP backpatching policy - Mailing list pgsql-hackers

From Craig Ringer
Subject [HACKERS] TAP backpatching policy
Date
Msg-id CAMsr+YFx8V73k5DR_Lgn+q7CTAfzSj90q92VOGGV7qohNBybUA@mail.gmail.com
Whole thread Raw
Responses Re: [HACKERS] TAP backpatching policy  (Michael Paquier <michael.paquier@gmail.com>)
Re: [HACKERS] TAP backpatching policy  (Stephen Frost <sfrost@snowman.net>)
Re: [HACKERS] TAP backpatching policy  (Robert Haas <robertmhaas@gmail.com>)
List 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



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256
Next
From: Craig Ringer
Date:
Subject: [HACKERS] pg_config --version-num