Check for new version of app during validation

[bdferris-v2]

Feature request

I'd like to propose a feature where the validation app automatically compares it's version number against the latest released version of the app and logs a notice if there is a newer version available. The old-school transitfeed validator had a similar feature and I think it was helpful for encouraging folks to run the latest version of the application. In light of the new packaged app, it's beneficial to get something like this implemented sooner rather than later, in order to have it in place for new users installing the application.

Is your feature request related to a problem? Please describe.
Folks tend to let software get stale and out-of-date if we don't prod them to upgrade.

Proposed solution
Similar to the transitfeed implementation, the app would read the content of a dedicate page on the gtfs-validator GitHub site, which would contain the latest released version number of the app. During validation, the app would read that page to find the latest version number and compare against its own internal version number in MANIFEST.MF. If the app is out-of-date, a notice would be added to the validation report.

Additional context
I am happy to do the implementation work on this if there is consensus that it is a worthwhile feature.

[barbeau]

I think this would be great.

Some thoughts:

1. Would the category of the notice be WARNING (vs ERROR or INFO)?
2. Might be nice to surface the version check in the GUI itself as well. One option would be an "About" menu option with current version info and "Check for updates" button. Do you think having a version check on GUI startup with a dialog if out-of-date is too invasive?

[bdferris-v2]

My thought here is that the version warning is different enough from other validation messages that it deserves to be separate in the UI. If we made it a Notice of any level (WARNING or INFO seem like the most likely choices) like any other validation notices, I worry it would get lost in the other validation notices.

So I think I'm proposing that we don't actually make this a regular Notice notice? Instead, we'd add an explicit check and generate explicit code for rendering it in the report (including a link to go download the new version of the app).

We could add a similar treatment in the app itself. I think a modal dialog might be too much. Instead, we could have a line inserted into the app dialog itself. Something like:

Imagine that the "Download" label is actually a link.

I'll acknowledge that the downside of the approaches outlined above is that for users who are just using the CLI app and writing json, they won't get any indication that their app is out of date.

[barbeau]

So I think I'm proposing that we don't actually make this a regular Notice notice? Instead, we'd add an explicit check and generate explicit code for rendering it in the report (including a link to go download the new version of the app).

The more I think about this, I think it's probably the best approach. The definitions of WARNING and ERROR are tightly coupled with the GTFS spec, which means if these are normal notices they would probably get relegated to INFO and ignored by most people. And, given that the CLI is being used in data pipelines it probably isn't a good idea to add non-critical network IO either, unless it's something that could be switched off via a command-line parameter.

Instead, we could have a line inserted into the app dialog itself.

LGTM

[isabelle-dr]

This is a great idea!
Since GTFS is evolving, this feature is even more relevant here IMHO. Let's say we add the Fares v2 rules & make a new release. If a user validates a dataset containing the fares v2 files & fields but uses an old release, a portion of the data will not be validated (and potentially be flagged as valid when it's not).

+1 for having this separated from the validator notices.

I'll acknowledge that the downside of the approaches outlined above is that for users who are just using the CLI app and writing json, they won't get any indication that their app is out of date.

Could we add a section at the top of the validation report?
We have already discussed adding a section to the validation report that would contain some metadata like:

• the validator version, the name of the dataset, the date.
• the number of routes & trips, service dates (see issue Include basic feed information in validation report  #1159)

This could be an opportunity to do it? It could look like

{
  "information": 
     {
        "version": 3.0.0,
        "updateNeeded": "download 3.0.1 to get the latest version of the app"
        "date": 2022-05-19 at 08:57:40 EDT
        "dataset": "file:///Users/isabelle/Desktop/Schedule_Validator/Archive.zip"
     }
  "notices": [
    {
      "code": "missing-Required_column",