Received: from localhost (maia-3.hub.org [200.46.204.184]) by postgresql.org (Postfix) with ESMTP id E39219FB54C; Mon, 30 Apr 2007 10:10:39 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.184]) (amavisd-maia, port 10024) with ESMTP id 09475-07; Mon, 30 Apr 2007 10:10:29 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from gmp-ea-fw-1.sun.com (gmp-ea-fw-1.sun.com [192.18.1.36]) by postgresql.org (Postfix) with ESMTP id C4A3F9FB2B4; Mon, 30 Apr 2007 10:10:34 -0300 (ADT) Received: from d1-emea-09.sun.com ([192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l3UDAX5x012846; Mon, 30 Apr 2007 13:10:33 GMT Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JHB00A01B8LJC00@d1-emea-09.sun.com> (original mail from Zdenek.Kotala@Sun.COM); Mon, 30 Apr 2007 14:10:33 +0100 (BST) Received: from [129.150.120.147] by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JHB00IMNB9J4Q50@d1-emea-09.sun.com>; Mon, 30 Apr 2007 14:10:32 +0100 (BST) Date: Mon, 30 Apr 2007 15:10:31 +0200 From: Zdenek Kotala Subject: Re: Feature freeze progress report In-reply-to: <4634FCFF.5040806@postgresql.org> To: Dave Page Cc: Stefan Kaltenbrunner , Heikki Linnakangas , Simon Riggs , Bruce Momjian , PostgreSQL-development Message-id: <4635EAC7.5040903@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200704270313.l3R3DwF16449@momjian.us> <1177792836.3663.61.camel@silverbirch.site> <46349EF4.2010304@enterprisedb.com> <4634EC25.6010104@postgresql.org> <4634F25C.3070403@kaltenbrunner.cc> <4634FCFF.5040806@postgresql.org> User-Agent: Thunderbird 1.5.0.8 (X11/20061204) X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200704/1245 X-Sequence-Number: 102578 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 >> an issue. > > 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. Zdenek