The other problem with an expiration, what happens when the devs forget to push a new version on schedule?
Don’t think it could happen? Would you believe last week that very thing happened with Mozilla Firefox on a security certificate breaking things for everyone globally that used the browser last weekend. https://arstechnica.com/information-technology/2019/05/firefox-add-ons-mass-disabled-by-certificate-bug-hotfix-for-some-ready/ Now, could you imagine what would happen if a forced expiration happened…say a couple days before some contest, and there wasn’t yet a new version out? Or the proposed thing of “what if you don’t have Internet”…what happens if you have a SOTA or DXpedition that requires more than a couple days of prep and you don’t realize that a new version came out between when you packed up and when you arrive, now your software is bricked? Requiring manual intervention to keep things working can and will fail sooner or later. -Matt / KK4NDE From: Matthew Miller [mailto:[email protected]] Sent: Friday, May 10, 2019 7:20 AM To: 'WSJT software development' Cc: 'Gustafson Neil' Subject: Re: [wsjt-devel] Expiration Date on Software Even easier than modifying the hosts file, I can just change the system date to get around an offline check. -Matt / KK4NDE From: [email protected] [mailto:[email protected]] Sent: Thursday, May 09, 2019 11:21 PM To: WSJT software development Cc: Gustafson Neil Subject: Re: [wsjt-devel] Expiration Date on Software 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]<mailto:[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]> [mailto:[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]<mailto:[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]<mailto:[email protected]> > https://lists.sourceforge.net/lists/listinfo/wsjt-devel _______________________________________________ wsjt-devel mailing list [email protected]<mailto:[email protected]> https://lists.sourceforge.net/lists/listinfo/wsjt-devel _______________________________________________ wsjt-devel mailing list [email protected]<mailto:[email protected]> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
_______________________________________________ wsjt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wsjt-devel
