On 09/06/2010 12:59, Russell Keith-Magee wrote:
Hi all,
While we support PostgreSQL, our documentation doesn't actually
specify a minimum supported version. We have a couple of features that
are no-ops for versions prior to 8.2 (savepoints and database
autocommit), but we don't actually document a minimum required
version.
We have a specified minimum of SQLite 3.3.6 and Oracle 9i (10g for
certain features); we have a vague suggestion that MySQL 4.1 is the
minimum supported version (but we don't rule out support for 3.23 and
4.0); but what is our policy with PostgreSQL? Do we support PostgreSQL
7.4?
PostgreSQL 7.4 was released in November 2005, and will be end-of-lifed
(along with PostgreSQL 8.0) in July this year. Our usual yardstick of
slow updates, RHEL4, shipped with PostgreSQL 7.4. RHEL5 shipped with
PostgreSQL 8.1.
Why am I asking? Because of r13328. In that changeset, I added a fix
for #8901 using a database function that is available in PostgreSQL
8.0, but not in PostgreSQL 7.4.
So - I'm looking for community opinion on how to deal with this. I can
see (at least) three options:
1) Rollback the changeset, and find a PostgreSQL 7.4-compatible way
of solving the problem. Continue to support PostgreSQL 7.4, and
formally document this fact.
2) Add documentation for 1.3 that imposes a PostgreSQL 8.0 minimum;
rollback r13328, wait until the 1.3 branch is forked, and reapply to
that branch. In other words treat #8901 as a feature, rather than a
bugfix, and introduce the Python 8.0 minimum as a new restriction for
1.3, much in the same way that we dropped support for Python 2.3 in
Django 1.2.
3) Retroactively modify the documentation saying Django 1.2 required
PostgreSQL 8.0 as a minimum. This treats the absence of a documented
minimum required version as a bug, and addresses the bug by picking a
minimum supported version that. r13328 stays as is.
Our general policy for deprecating old dependencies is something we
need to have a bigger discussion about -- especially as it relates to
Python itself -- but this PostgreSQL issue is immediate and pressing.
I certainly hope that any reasoning behind the decision we make for
PostgreSQL could be generalized to answer the same question for any
other dependency.
Opinions?
Yours,
Russ Magee %-)
So, my opnion on this is that we should drop 7.4 support, but I'm not
sure if it should be done in 1.3 or 1.2.
Firstly, from what I can find
(http://www.postgresql.org/docs/7.4/static/release-7-4.html), PostgreSQL
7.4 was released in 2003, not 2005, which puts it in the same
depreciation area as Python 2.3 (also 2003). RHEL4 itself was released
in 2005.
Given than 1.2 has dropped support for Python 2.3, and thus already
won't work on RHEL4, I see no real reason we should keep supporting 7.4,
especially if it's being EOL'd soon.
As for whether to apply the fix to 1.2 or 1.3, 1.3 seems a safer option,
but if there's no outcry from 7.4 users I'd be tempted to document 1.2
as being PostgreSQL 8.0 and up (after all, best to bundle one
RHEL4-breaking change with another). Given that it's a database, though,
people might want to keep running their old RHEL4 database boxes and
only upgrade their frontend servers, so it's definitely not easy to choose.
Still, I think option 1 is just going to hold Django back - there's a
few things they fixed in 8.0, most notably (for me) the implementation
of information_schema, which any PostgreSQL schema-altering backend is
going to want.
Andrew
--
You received this message because you are subscribed to the Google Groups "Django
developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
