Re: Release plan

It's rumoured that Andreas Pflug once said:
> Dave Page wrote:
>
>>Preview/Developer Releases
>>--------------------------
>>
>>These are useful to get feedback during the development phase.
>>Basically unsupported, and may be missing features, the idea is to get
>>feedback as we go, and find any major problems early on that may not be
>>spotted by us. We can release these following any major commits or task
>>completions.
>>
> That's what I'm offering at the moment at
> www.pse-consulting.de/pgadmin3/pgadmin3.zip. Maybe we should have a
> more  official place for this?

We can add it to the pgAdmin downloads page. I'll probably do a simple
installer as well.
>>2) Property editor/Creation dialogues for each object type.
>>
> Well, seems like a punishment to me... Do we really need ALL objects
> supported for a release? I believe for the first step we could reduce
> it  to the most used object types, omitting rarely used ones. Virtually
>  nobody will miss a Operator Class wizard...
>
> Here is my ranking with descending priority:
> - User (done)
> - Group
> - Table
> - View
> - Index
> - Foreign Key
> -- up to here, absolutely necessary for Beta-1, covers >90 % or work.
> ---------------------------
> - Function
> - Trigger
> - Rule
> - Sequence
> - Check
> -- coverage >99 % with this objects
> ---------------------------
> - Type
> - Domain
> - Operator
> - Aggregate
> - Conversion
> - Schema
> - Language
> - Database
> - Cast
> - Operator Class

Don't forget that Foreign Keys and Checks are part of the table dialogue
(remember pgAdmin II?). We *cannot* release without being able to create
databases and schemas (how would a new server get populated without using
SQL?) imho, and I'd also like to see Domains done as they are seriously
useful, even to the novice. How painful are these to produce really
anyway? In pgAdmin II the hard bit certainly wasn't the dialogues, but I
guess the IDE for VB is a little more useful for that.

>>
>>3) Table viewer/editor, with data save/export capable of handling a few
>>basic ASCII formats.
>>
> Which formats are needed?
> - CSV, with selectable separator, escape char, string delimiter, line
> delimiter

That'll cover just about everything. In the future I would like to add XML
and HTML page (title, plus table).

> - ?
>
>>4) Combined query tool, switchable between pure SQL entry and QBE
>>modes, with data save/export capable of handling a few basic ASCII
>>formats.
>>
> Export: same question as above.

Yup, let's use the same code.

>>Thoughts, comments?
>>
>>
> I totally agree to keep pgAdmin3 at a reasonable core functionality.
> Still, some maintenance tools for daily work should be included in the
> next release. VACUUM is one of them, and database backup and restore is
>  just the same level.

VACUUM is essential, but is trivial to do anyway. Database backup and
restore is not something I ever want pgAdmin to do - people will use it in
production, and it'll be too easy for us to get something wrong. At a push
I'd grudgingly do a frontend for pg_dump.
Regards, Dave