Skip to content

Commit

Permalink
chore: fix lint
Browse files Browse the repository at this point in the history
  • Loading branch information
snitin315 committed Feb 10, 2024
1 parent 01ea223 commit f1c0f64
Showing 1 changed file with 10 additions and 10 deletions.
20 changes: 10 additions & 10 deletions tools/fetch-stats.js
Original file line number Diff line number Diff line change
Expand Up @@ -62,36 +62,36 @@ async function fetchStatsFromGitHubAPI() {
*
* 1. `latestRelease` - This is the release tagged `latest` on the npm.
* For example, 8.56.0 or 9.0.0.
* In the terms of semver, this is the highest non-prerelease version.
* In the terms of semver, this is the highest non-prerelease version.
* 2. `currentRelease` - This is the release with the newest features.
* This is normally the same as `latestRelease` (for example, 8.56.0 or 9.0.0),
* but if we are in the process of publishing prereleases of the upcoming
* major version, this is the most recent prerelease (for example, 9.0.0-alpha.2),
* the one tagged `next` on the npm.
* In the terms of semver, this is the highest version.
*
*
* So, we need to find the highest version and the highest non-prerelease version.
* We're fetching releases from GitHub, which returns them ordered by creation date.
* This order typically already matches the semver order. However, if we've recently released
* some backport versions (e.g., v8.57.0 after 9.0.0-alpha.2), the order in the fetched
* some backport versions (e.g., v8.57.0 after 9.0.0-alpha.2), the order in the fetched
* list will not follow semver:
*
*
* 8.57.0
* 9.0.0-alpha.2
* 9.0.0-alpha.1
* 9.0.0-alpha.1
* 9.0.0-alpha.0
* 8.56.0
* ...
*
*
* To account for this case, we'll first sort versions by semver, in descending order:
*
*
* 9.0.0-alpha.2
* 9.0.0-alpha.1
* 9.0.0-alpha.1
* 9.0.0-alpha.0
* 8.57.0
* 8.56.0
* ...
*
* ...
*
*/
const releases = repository.releases.nodes.toSorted(
(first, second) => semver.rcompare(first.tagName, second.tagName)
Expand Down

0 comments on commit f1c0f64

Please sign in to comment.