Dave Page wrote:
Stefan Kaltenbrunner wrote:
This means that there is a huge rush of new code in pgAdmin's
development cycle, right at the time when we should be testing - making
the release process more and more rushed as each release of PostgreSQL
gets more efficient and adds more and more new features.
this is indeed an issue - but there is nothing that says that pgadminIII
has to support all the new features of a backend the they it get
released. pgadmin is decoupled from the min development cycle anyway so
adding support for a new features a few months later sounds not too much
No it's not decoupled; it runs almost exactly in sync. Our most popular
platform ships with pgAdmin as standard because thats what the users of
that platform expect. Not shipping with pgAdmin (or a functionally
complete one) would be like shipping SQL Server without Enterprise Manager.
And also from another point of view Postgres and related version of
PgAdmin must fit in same release cycle windows of OS distributions. When
OS release is out new feature is not usually accepted and OS should be
shipped with old version pgAdmin.
And bigger problem then new feature in pgAdmin is
pg_upgrade/pg_migrator. Upgrade procedure must be finished at same time
as new release, but some upgrade functions are possible coding only
after feature freeze or when all affected patches are committed.
If we want to have this feature (upgrade) in postgres we would adjust
release cycle anyway.
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster