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.
I should also point out that in ICT data exchange it's common practice to include a version in the meta-data to prevent exactly this issue. -- finger painting on glass is an inexact art - apologies for any errors in this scra^Hibble ()/)/)() ..ASCII for Onno.. On Fri., 10 May 2019, 11:22 [email protected], <[email protected]> wrote: > The online check is good except some may then modify hosts file and > similar to defeat it. If it comes with a kill switch if it can’t phone home > successfully then that may work out. An auto update feature, I suppose > > Older versions on the air did cause problems in the past. Some users hung > on to them either deliberately or unintentionally. > > 73 > Ria > N2RJ > > > On Thu, May 9, 2019 at 10:52 PM Matthew Miller <[email protected]> > wrote: > >> I would recommend against it -- how would you pick a reasonable date to >> ensure you don't need it to be updated sooner, and also not too soon that >> people have to reinstall just to update the date? >> >> A more reasonable approach would be to have it poll a file on the server >> that tells the software what the most recent version is that is released, >> and possibly have a flag or option telling it if the update will break >> backward-compatibility (like 2.0 did). Then you could have a nag screen >> that tells you to download the latest version X and links to the changelog. >> >> I will point out I was unaware for many months that v2.0 had come out >> because I had no reason to check the website since what I have was working >> fine. >> >> Also, at least for Linux distributions, you could set up a software >> repository channel instead of just having the download packages, this way >> the updates would be pushed out seamlessly to everyone in real time, other >> apps such as CHIRP do this and it is very convenient. I don't know if Mac >> has anything similar, I don't believe Windows does (unless you get set up >> in the Win10 store). >> >> Point is, for a beta the expiration makes sense like a trial expires. >> For production software, there are much more conventional reasonable ways >> to encourage users to update. >> >> -Matt / KK4NDE >> >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] >> Sent: Tuesday, May 07, 2019 7:19 PM >> To: WSJT software development >> Cc: Gustafson Neil >> Subject: Re: [wsjt-devel] Expiration Date on Software >> >> That's a good idea. Some held on to old versions so they could retain >> features that were detrimental to the herd, such as lock rx=tx. >> >> Expiring the versions is a very good idea. >> >> Ria >> N2RJ >> >> On Tue, 7 May 2019 at 19:14, Gustafson Neil via wsjt-devel < >> [email protected]> wrote: >> > >> > Hi All: >> > Recent mention of an expiration date on RC 5 of WSJT-X... Perhaps >> all releases of WSJT-X should expire in some reasonable timeframe. Today I >> debugged a failing FT8 station that had not been used as such in some >> months. After some effort in checking connections, config., etc., it was >> realized that release 1.8 was installed (e.g. obsolete payload format). >> One example of why older releases should be disabled at some point in time. >> > >> > Thanks and 73, >> > Neil W3ZQI >> > _______________________________________________ >> > 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 >
_______________________________________________ wsjt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wsjt-devel
