Re: The case for the One-Click Installer

On Thu, Jul 9, 2009 at 11:24 PM, Andreas Pflug<pgadmin(at)pse-consulting(dot)de> wrote:

> Dave, while you're showing some numbers about the installer hell (I know why
> I always tried to keep away from installers and build systems...), can you
> shed a little light on the "3 men working fulltime for some months on the
> installer": how much of that work was purely postgres related, and not
> reusable/sharable with EDB servers?
>
> AFAIR EDB had the installer for their own products first, and in a second
> step made it vanilla-postgres-aware. Of course there's absolutely nothing
> wrong with that, that's how OSS works. But all that uncountable windows
> issues apply to the EDB products as well, so a good bunch of code as well as
> experience gained from tests is shared.
> In this case, I guess pgsql8.4 is the first product tested, and edb8.4 will
> follow, gaining benefit from everything learned with pgsql. Again, there's
> absolutely nothing wrong about that, unless you try to induce the impression
> that EDB contributed manpower solely usable on vanilla-pgsql with no direct
> benefit for edb products, in order to justify why EDB should gain a premium
> marketing platform on the pgsql distribution as kickback. Actually, I did
> get that impression.

The PostgreSQL 8.3 one-click installers, and the 60 or so add-on
installers that are available through StackBuilder are the first of
our 'next generation' installers. The current version of Postgres Plus
Standard server (8.3) uses Apple's installer on Mac, Wix on Windows
and some Java thing on Linux. The current version Postgres Plus
Advanced Server (8.3R2) uses a java based Installshield installer.

The next version of Postgres Plus Standard Server (which will probably
be out in late Q3/Q4) will use the same technology as we're using for
PostgreSQL on all platforms. It will reuse a fair chunk of the
existing installers code, and was intentionally designed that way to
optimise the use of resources.

The next version of Advanced Server (no idea on the ETA of that) will
almost certainly use the same technology, but with significantly less
shared code, mainly because the products are quite different.

So currently, all of those resources have been dedicated purely to
PostgreSQL, but it is true that we will benefit from reduced/combined
testing requirements on Postgres Plus in the future.

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com