Should we nag discreetly about new GATE versions?

[johann-petrak]

It is probably not difficult to make GATE check whether it is at the latest version -- the release process could e.g. include a step that updates a file somewhere on the internet (e.g. another file in the gate-meta repository) which GATE could check at certain points (maybe where it needs to retrieve info from the internet anyway).
GATE could then more or less discreetly suggest to update and also provide a link for getting the newest release.
Not having this version info on gate-meta but on a server controlled by us would maybe allow us to get some very basic usage info (just the number of pings and the version of the pinging GATE, maybe the OS and java version, but no IP or similar).

[greenwoodma]

I was actually thinking about this as I was pushing the release button. I'd prefer to avoid another file we have to edit though, as it adds yet another step to the release procedure which is already long and complicated enough as it is.

Instead my suggestion is that when starting a release version of GATE (not a snapshot) to do a version range check against maven central for gate-core. We can then see what the latest release is and provide a message with an appropriate link etc. to the downloads page on GitHub.

We can then track download counts for the release using the standard GitHub API: https://developer.github.com/v3/repos/releases/ for use in reporting etc.

[greenwoodma]

or we could just use the json from GitHub to list the releases (https://developer.github.com/v3/repos/releases/#list-releases-for-a-repository) although I'm not sure how easy that would be to check version ordering etc. compared to the support we already have in GATE for doing range checks on gate-core

[ianroberts]

Nice, each release has a published_at date in the JSON so we could just pick the latest of those. I guess the usual mechanism for “check for updates” is to give the user the choice to download, remind again later or ignore (and in our case track in the user config the latest version number they have “ignored” so we know whether to prompt them again).

[greenwoodma]

We could either do it automatically and print a message, or have a menu for checking for updates. I think we might also want to handle bug fix releases differently; i.e. nag about 8.5 to 8.5.1 but let let them choose to check if they can go from 8.5 to 8.6 (via a menu item) as that suggests change in functionality rather than just bug fixes.

[greenwoodma]

As for stats, I was thinking of knocking something up myself but for now this is probably enough https://www.somsubhra.com/github-release-stats/?username=gatenlp&repository=gate-core

Long term I'd like to grab the info via the api on a regular basis so we can report not just total downloads but downloads within a given time period and plot nice graphs for proposals etc.

[johann-petrak]

I think the easiest first step if the version is checked at startup would then be to always inform (not nag) about a new release (bug fix or not) by simply adding to the startup message on the message pane?

The "nagging" could still be discreet by just making that message bigger and red, for example, if there is a bugfix release.

I am sceptical about pop ups or dialog windows, they introduce new complexity because then we probably need to store in config something like "dont show again" flags or similar (and how to store config should get a re-thinking anyway).

[greenwoodma]

Yes, I think a simple message on the message pane is enough, plus a menu item to force a check which could have a dialog wth more options etc.