Spurious IDE update notifications when using snapshot or nightly builds

[per1234]

Describe the problem

On every startup, the Arduino IDE checks for new versions of the IDE (#797). If a newer version is available, a notification/dialog is shown offering an update.

"Newer" is determined by comparing the version of the user's IDE to the latest available version on the update channel. This comparison is done according to semver.

In order to facilitate beta testing, builds are generated of the Arduino IDE at the current stage in development. These builds are given an identifying version of the following form:

• <version>-snapshot-<short hash> - builds generated for every push and pull request that modifies relevant files
• <version>-nightly-<YYYYMMDD> - daily builds of the tip of the default branch

The established project management practices cause the <version> component of these to be the version of the most recent release.

During the pre-release phase of the project development, all releases had a pre-release suffix (e.g., 2.0.0-rc9.4). Appending the "snapshot" or "nightly" suffix to that pre-release version caused these builds to have the correct precedence (e.g., 2.0.0-rc9.2.snapshot-20cc34c > 2.0.0-rc9.2). This situation has changed now that the project is using production release versions (e.g., 2.0.0-nightly-20220915 < 2.0.0)

🐛 Users of "snapshot" or "nightly" builds are presented with a spurious update notification on startup.

To reproduce

Setup

Make sure you have the default values of the relevant settings:

{
  "arduino.checkForUpdates": true,
  "arduino.ide.updateChannel": "stable"
}

Steps

1. Download the latest nightly build of Arduino IDE 2.x from the links on the "Software" page:
   https://www.arduino.cc/en/software#nightly-builds
2. Start the nightly build.

🐛 A spurious IDE update notification dialog appears:

Expected behavior

IDE update notification is only shown when a newer version of the Arduino IDE is available.

Arduino IDE version

2.0.0-snapshot-5f82577

Operating system

Windows

Operating system version

10

Additional context

I think the solution will be to add a step to the end of the release procedure to bump the version metadata after completing a release, following the same procedure as documented under the "Create the release on GitHub" section of that document.

I see two possible approaches:

• Use a pre-release of a patch bump (e.g., the metadata should currently be set to 2.0.1-rc.1)
• Use a patch bump (e.g., the metadata should currently be set to 2.0.1)

With the latter approach, the release manager could skip the metadata update step of the release unless the release was determined to be a minor or major version bump (according to the nature of the changes being shipped).

Issue checklist

• I searched for previous reports in the issue tracker
• I verified the problem still occurs when using the latest nightly build
• My report contains all necessary details

[sstaub]

Same problem on macOS