Re: Minimum supported version of Python?

Joshua D. Drake wrote
> On 03/17/2014 07:31 PM, Peter Eisentraut wrote:
>> 
>> On Sun, 2014-03-16 at 22:34 -0400, Tom Lane wrote:
>>> Well, if you want to consider python 2.3 as supported, I have a
>>> buildfarm
>>> machine I am about to put online that has 2.3 on it.  If I spin it up
>>> with
>>> python enabled, I expect you to see to it that it starts passing.  If
>>> you
>>> won't do that, I'm going to change the documentation.
>> 
>> As I said, according to my testing, 2.3 is supported.  If your
>> experience is different, then please submit a reproducible bug report.
>> 
>>> As for 2.4 vs 2.5, I don't have a lot of faith that we're really
>>> supporting anything that's not represented in the buildfarm...
>> 
>> There are many other features that the build farm doesn't test and that
>> I don't have a lot of faith in, but I'm not proposing to remove those.
>> I don't control what the build farm tests, I only control my own work.
> 
> We shouldn't be supporting anything the community doesn't support.
> Python 2.3 is dead. We shouldn't actively support it nor suggest that we
> could or should via the docs.
> 
> There is certainly an argument for Python 2.4 (due to CentOS/RHEL) but
> other than that... really?
> 
> JD

+1 generally though it ignores the bigger question which is how are we
actually defining and proving support; and also the whole we support 8.4
(for a little longer now) so what related technology should we be either
supporting or at least saying "ya know, this was working just fine 4 years
ago if you use exactly these versions, so use those versions."  A "last know
working version" in the plpythonu section wouldn't hurt since actively
running all the possible combinations for the 5 year support cycle doesn't
make sense.

Is Peter /the/ final arbiter of fact in this area or are there some public
buildfarm animals out there that have been designated to fulfill this role?

Peter claims to be doing the compiling and testing for these, which is great
and would be better if people like Tom actually were aware of that fact, but
comments suggest that such testing is currently done "offline".

To Peter's comment - reporting which version combinations are known to
compile is good but if a regression test exists then it should either pass
on a clean version or it should be documented (ideally right in the tests
themselves) what additional configuration is required (though maybe moving
that back to configure would be sufficient for our needs).  If there are no
coverage tests we are not asserting any proof anyway so if a release
compiles and passes regression tests it should be noted as such.  Once the
regressions start failing without any known fix it's hard to understand how
we could say such a combination is valid/supported anymore...

Supported - we will endeavor to fix bugs.  add the test case and then fix
the problem.

Compiles/Tests-OK - we know it worked at one point but if we discover a bug
we're more than likely to just say that the version is no longer supported
and known to have bugs.  Add the test case that causes regression to fail
and move on.

David J.




--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Minimum-supported-version-of-Python-tp5796175p5796516.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.