One of the challenges of automatic updating is package managers and such on the Linux side are often generations behind (not a big deal, but if a user installs Ubuntu, types "apt install wsjtx" and they still have 1.x in their repo it's going to confuse them) and trying to deal with those can be less than fun. As someone who's had to support a lot of users over the years (and has been a professional release engineer), automated updates can be difficult to get right and very easy to get wrong (proper cryptographic signing of packages, controls to ensure malware or unapproved features do not escape into a release, etc).
My opinion is that the occasional nag screen would be useful - call home to Princeton (or SF/Github/etc), if there's a update listed in a XML file it displays (and can be set to ignore) if not it just runs, it would have been useful during the 1.9-2.0 transition (I caught myself wondering one day a few months ago why a machine I don't use often but use occasionally for remote operating wasn't showing any FT8 with an accurate clock while the waterfall was chock full, it was because it was still on 1.9). If we're planning on ever "breaking" the encoding again, I think update alerts is a feature worth tossing in the next minor release (not 2.1) feature pile. 73 Adam N5YHF On Fri, May 10, 2019 at 10:06 AM WB5JJJ <[email protected]> wrote: > If the program on startup finds a valid Internet connection, then check > for an update automatically. If one is available, download it, or at least > supply a link to the file, and THEN allow the user to install (or delete) > it as they feel. Make it keep bugging the user on startup of WSJTx until > the update is done. Most software I use has this kind of feature. > > If the Internet is not available, allow the software to run as always, but > put up a warning that suggests the user check the website for an update. > This notice could happen on a weekly or even monthly schedule, or until the > Internet is restored. Or they could then use another computer with > Internet access, to download the software and install it on the one without > Internet. > > As was found with v1.9.1 expiring, many users downloaded it way back or > maybe had someone else install it for them and don't have a clue where to > check for updates. An update link in the About box would be very helpful > for those that forget where it came from. > > WB5JJJ - George > > On Fri, May 10, 2019 at 6:59 AM Onno Benschop <[email protected]> wrote: > >> Backwards compatibility is a thing ... >> >> Also, if the new version of the software knows how to decode an older >> encoding, you already have an implied version number. >> >> It's not like this takes eons to decode, nothing wrong with trying >> several times, newest version first, next version next and so on. >> -- >> finger painting on glass is an inexact art - apologies for any errors in >> this scra^Hibble >> >> ()/)/)() ..ASCII for Onno.. >> >> On Fri., 10 May 2019, 16:11 Reino Talarmo, <[email protected]> >> wrote: >> >>> Hi Onno, >>> >>> >A better idea is to include a protocol version number in the QSO >>> information, that way both sides have a chance to alert the operator. >>> >>> >>> >>> A nice idea, but that information needs to be sent using the lower layer >>> of the previous protocol version…. >>> >>> 73, Reino, oh3ma >>> _______________________________________________ >>> wsjt-devel mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel >>> >> _______________________________________________ >> wsjt-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/wsjt-devel >> > _______________________________________________ > wsjt-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/wsjt-devel >
_______________________________________________ wsjt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wsjt-devel
