Re: [wsjt-devel] Expiration Date on Software
Seems like the best way then would be if they maintain their own channel, as is the case with CHIRP, VirtualBox, and countless other applications. Then I could add that source and the package manager would use the more up to date packages seamlessly. The packages are already being built for a number of different platforms in the proper package formats, tossing them in a proper repository for each wouldn’t be a significant increase in effort. Side-note, I also encountered a problem where version 2.X seems to not be compiled against the correct glibc versions for Ubuntu 16.04-LTS base, which may be related to why its not updated in the Ubuntu channel if they are just picking up what is already built. I have been having to recompile it myself with 2.0 and 2.0.1 as well as the 2.1RC5. FWIW I had no idea about any update until a local ham told me about needing to update with 2.0 when I mentioned it one morning. The other idea would be as someone else suggested, put a "header" or something with a version that goes out over the air...now you won't have to make the software "phone home", it can simply decide the version the other people are sending and if its newer than what it has, tell the user "Hey, it looks like there is a newer protocol version, you should go to check for updates!" That would be a cross-platform solution without needing to worry about package managers or "phoning home" or Internet access at all. Maybe that would be the best way? -Matt / KK4NDE -Original Message- From: Christoph Berg [mailto:m...@debian.org] Sent: Friday, May 10, 2019 12:21 PM To: WSJT software development Subject: Re: [wsjt-devel] Expiration Date on Software Re: Adam Bartlett 2019-05-10 > 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). Also, updating a piece of software that came over some channel over a different channel will likely be annoying. So no automated downloads or whatever please. (Says the Debian maintainer.) > 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 Fwiw, it's part of the Debian policies that packages shouldn't call home without the user's consent (you can probably also derive that from the GDPR). Maybe that's less strict with hamradio software that is meant to be used publically, but still. I guess the biggest problem here is that we can't tell when a certain version should expire. 1.9.x is clearly dead, but 2.0.x will possibly work forever unless the protocol changes again... Not trying to fix that problem might actually be the smartest solution. Christoph DF7CB ___ 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
Re: [wsjt-devel] Expiration Date on Software
Re: Adam Bartlett 2019-05-10 > 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). Also, updating a piece of software that came over some channel over a different channel will likely be annoying. So no automated downloads or whatever please. (Says the Debian maintainer.) > 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 Fwiw, it's part of the Debian policies that packages shouldn't call home without the user's consent (you can probably also derive that from the GDPR). Maybe that's less strict with hamradio software that is meant to be used publically, but still. I guess the biggest problem here is that we can't tell when a certain version should expire. 1.9.x is clearly dead, but 2.0.x will possibly work forever unless the protocol changes again... Not trying to fix that problem might actually be the smartest solution. Christoph DF7CB ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Expiration Date on Software
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 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 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, >> 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 >>> 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
Re: [wsjt-devel] Expiration Date on Software
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 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, > 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 >> 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
Re: [wsjt-devel] Expiration Date on Software
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, 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 > 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
Re: [wsjt-devel] Expiration Date on Software
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:mmill...@mail.umw.edu] 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: rjai...@gmail.com [mailto:rjai...@gmail.com] 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 mailto: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> [mailto: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 mailto: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<mailto:wsjt-devel@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/wsjt-devel ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net<mailto:wsjt-devel@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/wsjt-devel ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net<mailto:wsjt-devel@lists.sourceforge.net> https://lists.sourcef
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: rjai...@gmail.com [mailto:rjai...@gmail.com] 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 mailto: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> [mailto: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 mailto: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<mailto:wsjt-devel@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/wsjt-devel ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net<mailto:wsjt-devel@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/wsjt-devel ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net<mailto: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
Re: [wsjt-devel] Expiration Date on Software
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 wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Expiration Date on Software
I would be against a kill switch if it can't phone home as this would restrict people to only using the program if they were online. This would stop people using it if they were located somewhere where there was no internet access. 73 Jonathan GI7KMC On Fri, 10 May 2019 at 04:23, rjai...@gmail.com 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 > 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 > ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Expiration Date on Software
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 rjai...@gmail.com, 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 > 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 > ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
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 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
Re: [wsjt-devel] Expiration Date on Software
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 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