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 <mmill...@mail.umw.edu> 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: rjai...@gmail.com [mailto:rjai...@gmail.com] > 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 < > wsjt-devel@lists.sourceforge.net> 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 > > wsjt-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > > > _______________________________________________ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > > > _______________________________________________ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel >
_______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
