[HACKERS] TAP backpatching policy

Поиск
Список
Период
Сортировка
От Craig Ringer
Тема [HACKERS] TAP backpatching policy
Дата
Msg-id CAMsr+YFx8V73k5DR_Lgn+q7CTAfzSj90q92VOGGV7qohNBybUA@mail.gmail.com
обсуждение исходный текст
Ответы 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>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256
Следующее
От: Craig Ringer
Дата:
Сообщение: [HACKERS] pg_config --version-num