Thread: RFC: Update wizard
Hi friends, preparing for the forthcoming 1.3/1.4 version, I'm already prototyping a little on automatic updates, and there are a lot of decisions to take. We have three areas to update: - The program itself. We will just notify the user that there's something new he might be interested in (depending on beta/release). - the current language. A word count can be used as version. Automatic download/installation possible. - a different language, which might require an update pgadmin3.lng too. Since the language isn't necessarily loaded, no version check can be performed. Questions: - How to inform the user about possible updates? MsgBox? Toolbar button showing enabled? Update check will be performed asynchronously, so it might pop up in the middle of something. - Dedicated update dialog or an options tab? - We could post some statistical data about the pga installation (OS/version/backend versions/server count/???) to get a little feedback; how to collect these? Multiple opinions welcome. Regards, Andreas
> -----Original Message----- > From: pgadmin-hackers-owner@postgresql.org > [mailto:pgadmin-hackers-owner@postgresql.org] On Behalf Of > Andreas Pflug > Sent: 21 November 2004 18:05 > To: pgadmin-hackers > Subject: [pgadmin-hackers] RFC: Update wizard > > Hi friends, > > preparing for the forthcoming 1.3/1.4 version, I'm already > prototyping a little on automatic updates, and there are a > lot of decisions to take. > > We have three areas to update: > - The program itself. We will just notify the user that > there's something new he might be interested in (depending on > beta/release). An option to download/install would be nice. That would require a separate program on Windows of course to update the main executable. > - the current language. A word count can be used as version. > Automatic download/installation possible. That won't necessarily pick up typos of course. Can we utilise CVS for this somehow, and use it's built in version numbering? That'll even allow segregation of major version updates using branch version numbers. > - a different language, which might require an update > pgadmin3.lng too. Yup. > Since the language isn't necessarily loaded, no version check > can be performed. No. Have you thought about documentation updates? > Questions: > - How to inform the user about possible updates? MsgBox? > Toolbar button showing enabled? Update check will be > performed asynchronously, so it might pop up in the middle of > something. Status bar message with flashing icon? > - Dedicated update dialog or an options tab? I would say both. A dialogue to handle the actual updating, and maybe one or two options to allow changes to the download location, enable/disable checking options etc. > - We could post some statistical data about the pga > installation (OS/version/backend versions/server count/???) > to get a little feedback; how to collect these? I'd love to see this sort of info, *however*, I have little doubt the privacy advocates would have something to say about it. I would be *very* wary of adding such a feature. Regards, Dave.
Dave Page wrote: > > > >>-----Original Message----- >>From: pgadmin-hackers-owner@postgresql.org >>[mailto:pgadmin-hackers-owner@postgresql.org] On Behalf Of >>Andreas Pflug >>Sent: 21 November 2004 18:05 >>To: pgadmin-hackers >>Subject: [pgadmin-hackers] RFC: Update wizard >> >>Hi friends, >> >>preparing for the forthcoming 1.3/1.4 version, I'm already >>prototyping a little on automatic updates, and there are a >>lot of decisions to take. >> >>We have three areas to update: >>- The program itself. We will just notify the user that >>there's something new he might be interested in (depending on >>beta/release). > > > An option to download/install would be nice. That would require a > separate program on Windows of course to update the main executable. What are you thinking about exactly ? A way to specify an external script/command to launch or something ? Under Linux and maybe others, I think that updaters generally do exactly the same thing, but generally less efficiently, as the native packaging systems. Example: I love the pear system for php but I consider that it clashes with the native packaging tools under Debian... By using pear system you get unpackaged files installed on your system. And what about things partly installed (example data files not up to date with binaries) which may break the app... I'd be for something advertising a new version but not more. Unless we have something really open and customisable to suits the needs of all OSes packagers. Regards, Raphaël
> -----Original Message----- > From: Raphaël Enrici [mailto:blacknoz@club-internet.fr] > Sent: 21 November 2004 21:39 > To: Dave Page; Andreas Pflug > Cc: pgadmin-hackers > Subject: Re: [pgadmin-hackers] RFC: Update wizard > > > What are you thinking about exactly ? A way to specify an external > script/command to launch or something ? Under Linux and maybe > others, I > think that updaters generally do exactly the same thing, but > generally > less efficiently, as the native packaging systems. Example: I > love the > pear system for php but I consider that it clashes with the native > packaging tools under Debian... By using pear system you get > unpackaged > files installed on your system. > And what about things partly installed (example data files not up to > date with binaries) which may break the app... > > I'd be for something advertising a new version but not more. > Unless we > have something really open and customisable to suits the needs of all > OSes packagers. Yeah, that's the downside. On some apps I've used on Windows, it's nice get have the app download a new version of itself,and spawn a new process to move the new version into place and run it. Makes it all seamless and very slick. Doesn'tfit in well with Linux packaging schemes though does it :-( Regards, Dave.
Dave Page wrote: >>We have three areas to update: >>- The program itself. We will just notify the user that >>there's something new he might be interested in (depending on >>beta/release). > > > An option to download/install would be nice. That would require a > separate program on Windows of course to update the main executable. Apart from packaging conflicts, IMHO it's not worth it. Pointing to the website should be sufficient. >>- the current language. A word count can be used as version. >>Automatic download/installation possible. > > > That won't necessarily pick up typos of course. Can we utilise CVS for > this somehow, and use it's built in version numbering? Not directly. The binaries would be corrupted. In the rare case of typo fixes without count change the count could be increased manually. It's a kind of version number anyway. We could use the date too. > That'll even allow segregation of major version updates using branch version numbers. We don't need that. A newer language file also covers previous versions. > Have you thought about documentation updates? Um, no. No problem really, because we already can load the doc from a zip. Consequently, we should stop distributing single files, and distribute the zip only. >>Questions: >>- How to inform the user about possible updates? MsgBox? >>Toolbar button showing enabled? Update check will be >>performed asynchronously, so it might pop up in the middle of >>something. > > > Status bar message with flashing icon? Annoying, if you don't want to update. Maybe non-flashing. Or toolbar button, which changes appearance if download is available. The download dlg should be accessible even if no update was automatically detected, to enable manual triggered updates. > >>- We could post some statistical data about the pga >>installation (OS/version/backend versions/server count/???) >>to get a little feedback; how to collect these? > > > I'd love to see this sort of info, *however*, I have little doubt the > privacy advocates would have something to say about it. I would be > *very* wary of adding such a feature. lets discuss this separately. Regards, Andreas
hi! Andreas Pflug wrote: > Annoying, if you don't want to update. Maybe non-flashing. > Or toolbar button, which changes appearance if download is available. > The download dlg should be accessible even if no update was > automatically detected, to enable manual triggered updates. could you also consider checking for a newer binary snapshot (for windows in my case)? so i wouldn't have to go look every now and then :) i know, i'm being lazy :) regards, Miha
> -----Original Message----- > From: Andreas Pflug [mailto:pgadmin@pse-consulting.de] > Sent: 22 November 2004 17:26 > To: Dave Page > Cc: pgadmin-hackers > Subject: Re: [pgadmin-hackers] RFC: Update wizard > > > That won't necessarily pick up typos of course. Can we > utilise CVS for > > this somehow, and use it's built in version numbering? > > Not directly. The binaries would be corrupted. In the rare > case of typo > fixes without count change the count could be increased > manually. It's a > kind of version number anyway. We could use the date too. Why would binaries be corrupted? > > That'll even allow segregation of major version updates > using branch version numbers. > > We don't need that. A newer language file also covers > previous versions. Does it? You mean, if we remove strings from the source, they remain in the po files after a merge? Seems kinda inefficient... > > Have you thought about documentation updates? > > Um, no. No problem really, because we already can load the doc from a > zip. Consequently, we should stop distributing single files, and > distribute the zip only. In that case then, why distribute the languages seperately? > >>Questions: > >>- How to inform the user about possible updates? MsgBox? > >>Toolbar button showing enabled? Update check will be > >>performed asynchronously, so it might pop up in the middle of > >>something. > > > > > > Status bar message with flashing icon? > > Annoying, if you don't want to update. Maybe non-flashing. As I also suggested though, there should be an option to turn off auto-checking on the options dialogue. But I could live with non flashing. > Or toolbar button, which changes appearance if download is available. No, I don't think we should use the tool bar. It's there to allow the user to control the application, not to provide feedback. > The download dlg should be accessible even if no update was > automatically detected, to enable manual triggered updates. Yes, agreed. Regards, Dave.
Dave Page wrote: >>Not directly. The binaries would be corrupted. In the rare >>case of typo >>fixes without count change the count could be increased >>manually. It's a >> kind of version number anyway. We could use the date too. > > > Why would binaries be corrupted? CVS would change the file to insert the version, which would probably corrupt the binary structure. > > >>We don't need that. A newer language file also covers >>previous versions. > > > Does it? You mean, if we remove strings from the source, they remain in > the po files after a merge? Right, that's what pgadmin3-release.pot is good for. We rarely remove strings, so this seems reasonable. > >>>Have you thought about documentation updates? >> >>Um, no. No problem really, because we already can load the doc from a >>zip. Consequently, we should stop distributing single files, and >>distribute the zip only. > > > In that case then, why distribute the languages seperately? I don't understand the question. We *do* distribute the languages packaged, no? > > > As I also suggested though, there should be an option to turn off > auto-checking on the options dialogue. But I could live with non > flashing. Disabling autocheck and not updating immediately are different things. > >>Or toolbar button, which changes appearance if download is available. > > No, I don't think we should use the tool bar. It's there to allow the > user to control the application, not to provide feedback. Every 60 days (e.g.) updates are checked, and a feedback is given to the user. After that, the user might decide to upgrade immediately, or do it later. Statusbar icon seems the best solution (but it will need some effort; tooltip and doubleclick on that icon must be supported) Regards, Andreas
Miha Radej wrote: > hi! > > Andreas Pflug wrote: > >> Annoying, if you don't want to update. Maybe non-flashing. >> Or toolbar button, which changes appearance if download is available. >> The download dlg should be accessible even if no update was >> automatically detected, to enable manual triggered updates. > > > could you also consider checking for a newer binary snapshot (for > windows in my case)? so i wouldn't have to go look every now and then :) > i know, i'm being lazy :) The update information checked by pgadmin will be created manually, i.e. it's a kind of release information. We're probably too lazy to update it for every snapshot ;-) Regards, Andreas
> -----Original Message----- > From: Andreas Pflug [mailto:pgadmin@pse-consulting.de] > Sent: 03 December 2004 12:18 > To: Dave Page > Cc: pgadmin-hackers > Subject: Re: [pgadmin-hackers] RFC: Update wizard > > Dave Page wrote: > >>Not directly. The binaries would be corrupted. In the rare case of > >>typo fixes without count change the count could be > increased manually. > >>It's a > >> kind of version number anyway. We could use the date too. > > > > > > Why would binaries be corrupted? > > CVS would change the file to insert the version, which would > probably corrupt the binary structure. No, it doesn't, unless it finds a placeholder such as $Id. Even then, I don't think it does so for binary files. > > In that case then, why distribute the languages seperately? > > I don't understand the question. We *do* distribute the > languages packaged, no? I think I was asking why we shouldn't include the languages in the update zip file, but it was a few days ago now :-) Forget about it! > > > > As I also suggested though, there should be an option to turn off > > auto-checking on the options dialogue. But I could live with non > > flashing. > > Disabling autocheck and not updating immediately are different things. The option controls the background checking for updates. If you then double click the alert icon, a dialogue is presented allowing you to select a mirror and download. Speaking of which, we will need to have a list of mirrors on the main webserver that can be downloaded... That is not a problem though. > Every 60 days (e.g.) updates are checked, and a feedback is > given to the user. After that, the user might decide to > upgrade immediately, or do it later. > Statusbar icon seems the best solution (but it will need some > effort; tooltip and doubleclick on that icon must be supported) Yeah. Regards, Dave.
Dave Page wrote: > > > > > No, it doesn't, unless it finds a placeholder such as $Id. Even then, I > don't think it does so for binary files. Of course $Id would be necessary. But if CVS doesn't stamp the file, how do you want CVS to handle the revision marking? > I think I was asking why we shouldn't include the languages in the > update zip file, but it was a few days ago now :-) Forget about it! ?!? You can consider zip as another compression/packaging format, similar to chm. I'm not sure whether wxLocale can handle this too. >>>As I also suggested though, there should be an option to turn off >>>auto-checking on the options dialogue. But I could live with non >>>flashing. >> >>Disabling autocheck and not updating immediately are different things. > > > The option controls the background checking for updates. If you then > double click the alert icon, a dialogue is presented allowing you to > select a mirror and download. Its not as easy as that... for pgadmin base package, I'd only inform about new packages. I wonder if we can do this even system specific, i.e. inform about deb packages on debian, ... For languages, a more complex selection for updating existing and adding new ones is necessary. Regards, Andreas
> -----Original Message----- > From: Andreas Pflug [mailto:pgadmin@pse-consulting.de] > Sent: 03 December 2004 13:19 > To: Dave Page > Cc: pgadmin-hackers > Subject: Re: [pgadmin-hackers] RFC: Update wizard > > > No, it doesn't, unless it finds a placeholder such as $Id. > Even then, > > I don't think it does so for binary files. > > Of course $Id would be necessary. But if CVS doesn't stamp > the file, how do you want CVS to handle the revision marking? CVS doesn't have to mark the file internally. Consider what happens if you try to check out a specific revision of a file - we can do that via the web, eg: http://cvs.pgadmin.org/cgi-bin/viewcvs.cgi/pgadmin3/src/ui/ar_SA/pgadmin 3.po?rev=1.20 Gets us rev 1.20. In a similar was it shouldn't be difficult to query cvs for the latest version number of a given file. > Its not as easy as that... > for pgadmin base package, I'd only inform about new packages. > I wonder if we can do this even system specific, i.e. inform > about deb packages on debian, ... Even if it just opened a browser at the selected mirror it would be helpful. Other than that, how do we determine the exact OS (ie. the difference between redahat9 and suse8 for example)? > For languages, a more complex selection for updating existing > and adding new ones is necessary. Yeah, though that shouldn't be a major problem as they're platform independent. Regards, Dave.
Dave Page wrote: > > > >>-----Original Message----- >>From: Andreas Pflug [mailto:pgadmin@pse-consulting.de] >>Sent: 03 December 2004 13:19 >>To: Dave Page >>Cc: pgadmin-hackers >>Subject: Re: [pgadmin-hackers] RFC: Update wizard >> >> >>>No, it doesn't, unless it finds a placeholder such as $Id. >> >>Even then, >> >>>I don't think it does so for binary files. >> >>Of course $Id would be necessary. But if CVS doesn't stamp >>the file, how do you want CVS to handle the revision marking? > > > CVS doesn't have to mark the file internally. Consider what happens if > you try to check out a specific revision of a file - we can do that via > the web, eg: > > http://cvs.pgadmin.org/cgi-bin/viewcvs.cgi/pgadmin3/src/ui/ar_SA/pgadmin > 3.po?rev=1.20 > > Gets us rev 1.20. > > In a similar was it shouldn't be difficult to query cvs for the latest > version number of a given file. First, do we really want to hammer CVS for each update check? I'd think having this in an "available versions" file is sufficient. Second, the issue is not to retrieve a version, but to identify the version of the language file currently in use. We need an identifyable string inside the file for that. Regards, Andreas
> -----Original Message----- > From: Andreas Pflug [mailto:pgadmin@pse-consulting.de] > Sent: 03 December 2004 13:53 > To: Dave Page > Cc: pgadmin-hackers > Subject: Re: [pgadmin-hackers] RFC: Update wizard > > First, do we really want to hammer CVS for each update check? > I'd think having this in an "available versions" file is sufficient. As long as that file can be (and is) automatically updated. > Second, the issue is not to retrieve a version, but to > identify the version of the language file currently in use. > We need an identifyable string inside the file for that. More preciesly, the issue is to detect whether a file has been updated. I suggested CVS as it should be simple to initial look for a file newer than the releases CVS tag, and following that, newer than the one previously downloaded. It also reduces the administration overhead. Mind you, maybe I'm underestimating the number of users we may get. Perhaps this should work from the ftp mirror network? Regards, Dave.
Dave Page wrote: > > > > > More preciesly, the issue is to detect whether a file has been updated. > I suggested CVS as it should be simple to initial look for a file newer > than the releases CVS tag, and following that, newer than the one > previously downloaded. But we don't want to create a kind-of cvs client in pgadmin, no? How to identify the currently installed versions, if not with a version string compiled in? > > Mind you, maybe I'm underestimating the number of users we may get. > Perhaps this should work from the ftp mirror network? I've been asking about this a while ago. We don't know until we try, I'm afraid... Regards, Andreas
> -----Original Message----- > From: Andreas Pflug [mailto:pgadmin@pse-consulting.de] > Sent: 03 December 2004 14:46 > To: Dave Page > Cc: pgadmin-hackers > Subject: Re: [pgadmin-hackers] RFC: Update wizard > > Dave Page wrote: > > > > > > > > > > > More preciesly, the issue is to detect whether a file has > been updated. > > I suggested CVS as it should be simple to initial look for a file > > newer than the releases CVS tag, and following that, newer than the > > one previously downloaded. > > But we don't want to create a kind-of cvs client in pgadmin, > no? How to identify the currently installed versions, if not > with a version string compiled in? For a new install, get the file if it is newer than the build date. Once a file is downloaded, it's modification date is logged in the registry and used for future checks. I wasn't proposing a CVS client in pgAdmin BTW - viewcvs with appropriate templates should be easily parse-able, and it can certainly serve files of any version, from any branch. > > > > Mind you, maybe I'm underestimating the number of users we may get. > > Perhaps this should work from the ftp mirror network? > > I've been asking about this a while ago. We don't know until > we try, I'm afraid... No, but it might be better to assume the worst... Doing it this way, it shouldn't be too difficult to automate an extraction from CVS onto the master server, and generate an index file of what's there. The more I think about it, the more that seems the best option... Regards, Dave.
Dave Page wrote: > > > For a new install, get the file if it is newer than the build date. Where does the build date come from? > No, but it might be better to assume the worst... Depends on the point of view :-) > Doing it this way, it shouldn't be too difficult to automate an > extraction from CVS onto the master server, and generate an index file > of what's there. The more I think about it, the more that seems the best > option... +1 vote from me. Regards, Andreas
> -----Original Message----- > From: Andreas Pflug [mailto:pgadmin@pse-consulting.de] > Sent: 03 December 2004 15:24 > To: Dave Page > Cc: pgadmin-hackers > Subject: Re: [pgadmin-hackers] RFC: Update wizard > > Dave Page wrote: > > > > > > For a new install, get the file if it is newer than the build date. > > Where does the build date come from? __TDATE__ in the main executable. It's fairly safe to assume that a distribution will be compiled and packaged on the same day. Regards, Dave.
Dave Page wrote: > > > >>-----Original Message----- >>From: Andreas Pflug [mailto:pgadmin@pse-consulting.de] >>Sent: 03 December 2004 15:24 >>To: Dave Page >>Cc: pgadmin-hackers >>Subject: Re: [pgadmin-hackers] RFC: Update wizard >> >>Dave Page wrote: >> >>> >>> >>>For a new install, get the file if it is newer than the build date. >> >>Where does the build date come from? > > > __TDATE__ in the main executable. It's fairly safe to assume that a > distribution will be compiled and packaged on the same day. I was afraid you mentioned __TDATE__. This is evaluated at compile time, i.e. precautions must be taken that the file must be compiled even if unchanged. Second, the date is formatted, i.e. we must unformat it locale/lib/compiler/??? dependent before examining. Regards, Andreas
> -----Original Message----- > From: Andreas Pflug [mailto:pgadmin@pse-consulting.de] > Sent: 03 December 2004 16:08 > To: Dave Page > Cc: pgadmin-hackers > Subject: Re: [pgadmin-hackers] RFC: Update wizard > > I was afraid you mentioned __TDATE__. > This is evaluated at compile time, i.e. precautions must be > taken that the file must be compiled even if unchanged. I do a 'make clean;make all' or 'Rebuild All' as a matter of course anyway - I would hope the other packagers do as well. > Second, the date is formatted, i.e. we must unformat it > locale/lib/compiler/??? dependent before examining. Hmm, shouldn't be - __DATE__ is supposed to always be "Mmm dd yyyy" iirc. __TDATE__ is wx's Unicode version so should be the same. Dunno if the Mmm ever appears in different languages though. /D
Dave Page wrote: > > > > >>Second, the date is formatted, i.e. we must unformat it >>locale/lib/compiler/??? dependent before examining. > > > Hmm, shouldn't be - __DATE__ is supposed to always be "Mmm dd yyyy" > iirc. __TDATE__ is wx's Unicode version so should be the same. Dunno if > the Mmm ever appears in different languages though. That's the part I'm afraid about. Win32 doc says only "using asctime() format". asctime doc doesn't say anything about language dependency. Regards, Andreas