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
