Thread: Re: Release plan
> -----Original Message----- > From: Andreas Pflug [mailto:Andreas.Pflug@web.de] > Sent: 26 April 2003 12:33 > To: Dave Page; pgadmin-hackers@postgresql.org > Subject: Release plan > > > what features make a preview release? Which are needed for beta, and > which for first V1.0? > Don't you think it's time for a release plan? IMHO you are > the one and > only master to do this :-) OK, in lew of an actual document... 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. Beta Releases ------------- Beta release will be just like any other - we will feature freeze and go into bug fixing mode. As I said in my earlier email on plugins, I want to avoid non-core features of pgAdmin for the first release, and provide just schema and data management support *in full*. I think that should include: 1) Schema browser capable of browsing all object types, including those missing from pgAdmin II, such as operator classes, rules/triggers under views and user/database variables. 2) Property editor/Creation dialogues for each object type. 3) Table viewer/editor, with data save/export capable of handling a few basic ASCII formats. 4) Combined query tool, switchable between pure SQL entry and QBE modes, with data save/export capable of handling a few basic ASCII formats. Of course, I'm open to discussion on this... As for timetable, to be honest that depends a lot on you guys. As you know, I'm in the middle of a course at Uni at the moment so am pretty tight for time (though I have been working my way through straightening up the properties and SQL generation). Mark starts the same course in 2 weeks when he returns from a holiday, so he's in the same boat. Thoughts, comments? Regards, Dave.
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? > >Beta Releases >------------- > >Beta release will be just like any other - we will feature freeze and go >into bug fixing mode. As I said in my earlier email on plugins, I want >to avoid non-core features of pgAdmin for the first release, and provide >just schema and data management support *in full*. I think that should >include: > >1) Schema browser capable of browsing all object types, including those >missing from pgAdmin II, such as operator classes, rules/triggers under >views and user/database variables. > > Done. I don't have rules and operator classes test cases, would you please check them? User and database variables implemented. >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 > >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 - ? >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. >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. Regards, Andreas
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
Dave Page wrote: >We can add it to the pgAdmin downloads page. I'll probably do a simple >installer as well. > Do we need this for a preview? It's simply unzipping and double click on pgAdmin.exe... >>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?). > This is a point of discussion. Should this really be done in one monster dialog or better be split into separate ones? >We *cannot* release without being able to create >databases and schemas (how would a new server get populated without using >SQL?) > Well, since they are simply "CREATE objectType name" to get up and running... > 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? > So your must-have list for a beta release looks like this: Group, Table, View, Index, Foreign Key, Check, Domain, Database, Schema >VACUUM is essential, but is trivial to do anyway. > Yup. >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. > I disagree. pgadmin3 should support every day work, and backup/restore is one part of it. I agree that this is some kind of advanced feature, available only to superusers after enabling the backup option. Regards, Andreas
> -----Original Message----- > From: Andreas Pflug [mailto:Andreas.Pflug@web.de] > Sent: 01 May 2003 14:22 > To: Dave Page; pgadmin-hackers@postgresql.org > Subject: Re: Release plan > > > Dave Page wrote: > > >We can add it to the pgAdmin downloads page. I'll probably > do a simple > >installer as well. > > > Do we need this for a preview? It's simply unzipping and > double click on > pgAdmin.exe... No, it's not essential, but should be tested at some point. > I disagree. pgadmin3 should support every day work, and > backup/restore > is one part of it. I agree that this is some kind of advanced > feature, > available only to superusers after enabling the backup option. Do you want to take the responsibility of getting the dump slightly wrong and someone finding they've lost their data or it's been corrupted? I certainly don't. If however, we can build in pg_dump, or provide a front end to it and display suitable messages whenever we find a version mismatch, then I would be a lot more happy to include such functionality. Regards, Dave
Dave Page wrote: >Do you want to take the responsibility of getting the dump slightly >wrong and someone finding they've lost their data or it's been >corrupted? I certainly don't. If however, we can build in pg_dump, or >provide a front end to it and display suitable messages whenever we find >a version mismatch, then I would be a lot more happy to include such >functionality. > > I don't have problems taking the responsibility. If I'm being paid to do so... If the "backup wizard" isn't smart enough to cope with potential user handling problems it's obviously not worth being integrated into pgadmin3 :-) Regards, Andreas
Guys, My $0.025767: I'd love to try a "preview release" of pgAdminIII, regardless of whether or not it's missing a few features (such as CREATE DATABASE and backup manager) However, I won't be able to try it unless a .tar.gz is available for Linux. So long as you make sure that the download page prominently labels it an alpha release, people should be smart enough not to rely on it for production work. -- Josh Berkus Aglio Database Solutions San Francisco
> -----Original Message----- > From: Andreas Pflug [mailto:Andreas.Pflug@web.de] > Sent: 01 May 2003 15:52 > To: Dave Page; pgadmin-hackers@postgresql.org > Subject: Re: Release plan > > > Dave Page wrote: > > >Do you want to take the responsibility of getting the dump slightly > >wrong and someone finding they've lost their data or it's been > >corrupted? I certainly don't. If however, we can build in > pg_dump, or > >provide a front end to it and display suitable messages whenever we > >find a version mismatch, then I would be a lot more happy to include > >such functionality. > > > > > I don't have problems taking the responsibility. If I'm being > paid to do > so... :-) Same here, but I'm not... > If the "backup wizard" isn't smart enough to cope with potential user > handling problems it's obviously not worth being integrated into > pgadmin3 :-) It's not so much the users as us. It's easy to get the SQL regeneration slightly wrong, or export data in a slightly incompatible format. Why recreate all those problems already solved by the pg_dump maintainers? Perhaps we can get the guts of pg_dump compiled into a library though and use that tried and test code with our own GUI? Regards, Dave.
> -----Original Message----- > From: Josh Berkus [mailto:josh@agliodbs.com] > Sent: 01 May 2003 16:06 > To: Andreas Pflug; Dave Page; pgadmin-hackers@postgresql.org > Subject: Re: [pgadmin-hackers] Release plan > > > Guys, > > My $0.025767: > > I'd love to try a "preview release" of pgAdminIII, regardless > of whether or > not it's missing a few features (such as CREATE DATABASE and > backup manager) > However, I won't be able to try it unless a .tar.gz is > available for Linux. I'm sure we can arrange that... :-) > So long as you make sure that the download page prominently > labels it an alpha > release, people should be smart enough not to rely on it for > production work. Yeah, I've got no problem with preview/alpha releases - I'd just rather go beta with at least full basic functionality whilst Andreas seems happy to leave out some of the lesser-used object types and get a first release out more quickly. Regards, Dave.
Josh Berkus wrote: >Guys, > >My $0.025767: > >I'd love to try a "preview release" of pgAdminIII, regardless of whether or >not it's missing a few features (such as CREATE DATABASE and backup manager) >However, I won't be able to try it unless a .tar.gz is available for Linux. > > > Josh, there's one at www.pse-consulting.de/pgadmin3/pgAdmin3.tar.gz, compiled under Suse 8.1 kernel 2.4.19. It's updated less frequently than the w32 version, but at this very moment it's fresh. Regards, Andreas