Re: TAP backpatching policy

Tom,

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Stephen Frost <sfrost(at)snowman(dot)net> writes:
> > * Craig Ringer (craig(at)2ndquadrant(dot)com) wrote:
> >> 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.
>
> > Makes sense to me.
>
> Um ... but we still have 2 live pre-9.4 branches. If your proposal
> doesn't extend to back-porting all of this stuff as far as 9.2,
> I don't see what this is really buying. We'd still need version cutoff
> checks in the tests.

I don't believe the explicit goal of this is to remove the version
checks but rather to provide improved testing coverage in our
back-branches. If we have to keep a version cutoff check for that, so
be it.

> (If you *do* propose back-patching all this stuff as far as 9.2, I'm not
> quite sure what I'd think about that. But the proposal as stated seems
> like questionable half measures.)

I find that to be an extremely interesting idea, for my own 2c, but I'm
not sure how practical it is.

Based on all of the feedback and discussion, I'm really inclined to
suggest that we support an alternative testing structure to the in-repo
regression suite. Such a testing structure would allow us to have,
perhaps, somewhat longer running tests than what developers run
typically (frankly, we already have this, but we have perversely decided
that it's "ok" when it's a configure option or a #define, but seemingly
not otherwise), or tests built in a framework which simply didn't exist
at the time of the major release which is being tested (such as the TAP
tests), but wouldn't also force the burden of supporting those tests on
our packagers (which has the other advantage of avoiding pushing new
requirements on those packagers, which might be quite difficult to
fulfill).

In the end, the experiences I've had with pg_dump of late and trying to
ensure that pg_dump 9.6 is able to work all the way back to *7.0*, makes
me think that this notion of putting the one-and-only real test-suite we
have into the core repo almost laughable. We aren't going to back-patch
things into 7.0, nor are we likely to run 7.0 across all members of the
buildfarm, so how are we to test the combinations which we claim to
support? On one-off builds/installs on individual developer systems
with, in some cases, hacked-up versions of PG (just to get them to
build!). Is that really testing what we're worried about? Perhaps in a
few cases, but I've little doubt that any serious 7.0-era deployment is
going to require more effort to migrate forward than running a 9.6
pg_dump against it.

That does push back a bit on if we should really be trying to support
such ancient versions, but I have to admit that I'm as much of a pureist
as anyone in that regard and I'd really hate to drop support for those
older branches too, at least for pg_dump, since that's how one moves
forward.

Thanks!

Stephen