• Icon: New Feature New Feature
    • Resolution: Fixed
    • Icon: Normal Normal
    • 2.1
    • None
    • None
    • None

      A maximum of once per week, at start-up Picard should check to see whether there is a new official version and if so inform the user (with a URL for download).

          [PICARD-1045] Check for new version

          Philipp Wolfer added a comment - https://github.com/metabrainz/picard/pull/904

          Bob Swift added a comment -

          When the PR is submitted, the code will have changed slightly from that posted in the previous comment. The version tuple comparison function will be moved to the picard/util/_init_.py file rather than the file with the UpdateCheckManager class. This is to avoid issues when trying to perform unit tests on the function because the checkupdate.py file imports picard.tagger. The comparison function will also zero out the fifth element of a test item if the version type for that item is 'final'. That came up as an issue during unit testing here. A unit test file (currently containing 52 tests of the comparison function) will also be included.

          Bob Swift added a comment - When the PR is submitted, the code will have changed slightly from that posted in the previous comment. The version tuple comparison function will be moved to the picard/util/_ init _.py file rather than the file with the UpdateCheckManager class. This is to avoid issues when trying to perform unit tests on the function because the checkupdate.py file imports picard.tagger. The comparison function will also zero out the fifth element of a test item if the version type for that item is 'final'. That came up as an issue during unit testing here. A unit test file (currently containing 52 tests of the comparison function) will also be included.

          Bob Swift added a comment -

          The framework code in the original PR submitted acquired the latest release version number by scraping the Picard website home page. There was a request from samj1912 to change this to an API response on picard-website with the user able to subscribe to one of three update levels (i.e.: stable, beta, dev). Updates checked for the three levels would be:
          -

          Subscription Level Stable Versions Beta Versions Development Versions
          stable yes no no
          beta yes yes no
          dev yes yes yes

          -
          Further, the request was that the latest version information for the three subscription levels should be stored in the default_config.py file. See the IRC log for details.

          It was subsequently identified that the latest version information was already available in JSON format from the GitHub API. The information available at https://api.github.com/repos/metabrainz/picard/releases only includes actual releases including those marked as pre-release (which was used for the 2.0.0beta1 release). All other tag information is available at https://api.github.com/repos/metabrainz/picard/git/refs/tags. This information can be used to populate the three update levels as:
          -

          Level Picard Version Type GitHub API End Point GitHub Pre-Release Flag
          stable final /repos/metabrainz/picard/releases false
          beta dev /repos/metabrainz/picard/releases true
          dev dev /repos/metabrainz/picard/git/refs/tags n/a

          -
          An updated checkupdate.py module has been developed for Picard, taking into account the comments from the initial PR and utilizing the version information from the GitHub API. It currently only uses the release information from GitHub, pending confirmation that the development level tag information should also be included (i.e.: the third subscription level). A copy of this current working draft is attached. checkupdate.py

          An option for manually checking for updates has been added to the main Picard window toolstrip under the Help section. This enabled the the updated checkupdate.py module to be tested with actual calls to the GitHub API and version tuple comparisons.

          The Options page regarding program update checking and automated checking at start-up has not yet been implemented, pending confirmation of the options to include. For example, the update notification subscription level options (i.e.: stable only, stable and beta, or all three), and options for automatic update checking intervals (e.g.: daily, weekly, monthly, never).

          The PR has not yet been updated and reopened.  This is not planned to occur until after the Picard 2.0 release, so as to avoid violating the "feature freeze" and distracting the development team from achieving their target release date.

          Bob Swift added a comment - The framework code in the original PR submitted acquired the latest release version number by scraping the Picard website home page. There was a request from samj1912 to change this to an API response on picard-website with the user able to subscribe to one of three update levels (i.e.: stable, beta, dev). Updates checked for the three levels would be: - Subscription Level Stable Versions Beta Versions Development Versions stable yes no no beta yes yes no dev yes yes yes - Further, the request was that the latest version information for the three subscription levels should be stored in the default_config.py file. See the IRC log for details. It was subsequently identified that the latest version information was already available in JSON format from the GitHub API. The information available at https://api.github.com/repos/metabrainz/picard/releases only includes actual releases including those marked as pre-release (which was used for the 2.0.0beta1 release). All other tag information is available at https://api.github.com/repos/metabrainz/picard/git/refs/tags . This information can be used to populate the three update levels as: - Level Picard Version Type GitHub API End Point GitHub Pre-Release Flag stable final /repos/metabrainz/picard/releases false beta dev /repos/metabrainz/picard/releases true dev dev /repos/metabrainz/picard/git/refs/tags n/a - An updated checkupdate.py module has been developed for Picard, taking into account the comments from the initial PR and utilizing the version information from the GitHub API. It currently only uses the release information from GitHub, pending confirmation that the development level tag information should also be included (i.e.: the third subscription level). A copy of this current working draft is attached. checkupdate.py An option for manually checking for updates has been added to the main Picard window toolstrip under the Help section. This enabled the the updated checkupdate.py module to be tested with actual calls to the GitHub API and version tuple comparisons. The Options page regarding program update checking and automated checking at start-up has not yet been implemented, pending confirmation of the options to include. For example, the update notification subscription level options (i.e.: stable only, stable and beta, or all three), and options for automatic update checking intervals (e.g.: daily, weekly, monthly, never). The PR has not yet been updated and reopened.  This is not planned to occur until after the Picard 2.0 release, so as to avoid violating the "feature freeze" and distracting the development team from achieving their target release date.

            rdswift Bob Swift
            sophist Sophist
            Votes:
            2 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved:

                Version Package
                2.1