sbp commented on issue #1145: URL: https://github.com/apache/tooling-trusted-releases/issues/1145#issuecomment-4244535712
In PR #1164, we consider restoring Mermaid to version 11.14.0 which has been tested and now works. This is puzzling because version 11.14.0 is the same version that I tested in this issue and found not to work. The PR description says that it was "published April 3, 2026", but both [npm metadata](https://www.npmjs.com/package/mermaid?activeTab=versions) and [GitHub metadata](https://github.com/mermaid-js/mermaid/releases/tag/mermaid%4011.14.0) say that it was published on April 1. That's still just within our 14 day cooldown window, so `make bump-bootstrap ...` didn't even work for me: ``` + npm install [email protected] '--before=2026-03-31T13:42:11Z' npm error code ETARGET npm error notarget No matching version found for [email protected] with a date before 3/31/2026, 1:42:11 PM. npm error notarget In most cases you or one of your dependencies are requesting a package version that doesn't exist. npm error A complete log of this run can be found in: /opt/bootstrap/.npm/_logs/2026-04-14T13_42_13_914Z-debug-0.log make: *** [bump-bootstrap] Error 1 ``` But manually changing it to a 7 day cooldown again actually does work: ``` docker run --rm \ -v "$PWD/bootstrap/source:/opt/bootstrap/source" \ atr-bootstrap /opt/bootstrap/bump.sh 5.3.8 + '[' 1 -ne 1 ] + VERSION=5.3.8 + SOURCE=/opt/bootstrap/source + cd /opt/bootstrap/source + command -v npm + SECONDS_AGO=604800 + date '+%s' + date -u -d @1775569387 '+%Y-%m-%dT%H:%M:%SZ' Using 7-day cooldown: --before=2026-04-07T13:43:07Z + CUTOFF=2026-04-07T13:43:07Z + echo 'Using 7-day cooldown: --before=2026-04-07T13:43:07Z' + rm -rf node_modules package-lock.json + npm install [email protected] '--before=2026-04-07T13:43:07Z' added 130 packages, and audited 131 packages in 10s found 0 vulnerabilities Checking for known vulnerabilities... + echo 'Checking for known vulnerabilities...' + npm audit found 0 vulnerabilities Verifying registry signatures... + echo 'Verifying registry signatures...' + npm audit signatures audited 130 packages in 1s 130 packages have verified registry signatures 14 packages have verified attestations (use --json --include-attestations to view attestation details) Bootstrap updated to version 5.3.8 Please commit the updated package.json and package-lock.json + echo 'Bootstrap updated to version 5.3.8' + echo 'Please commit the updated package.json and package-lock.json' ``` I figured that Mermaid and the other packages that depend on lodash-es probably use an open range, and that the resolution from that range had now moved on. Indeed, that seems to be the case: ``` $ rg lodash-es bootstrap/source/package-lock.json 434: "lodash-es": "^4.17.21" 960: "lodash-es": "^4.17.21" 1068: "node_modules/lodash-es": { 1070: "resolved": "https://registry.npmjs.org/lodash-es/-/lodash-es-4.18.1.tgz", 1107: "lodash-es": "^4.17.23", ``` Presumably, therefore, what happened here is that because lodash-es 4.18.1 was published on April 1 in the evening, when I lowered the cooldown to 7 days today it became available for resolving. When I opened this issue, however, it was the afternoon of April 8, which was _just_ inside the 7 day window and so 4.18.1 was not yet available to resolve. If I'd tried it the next day, or at night on the same day, I would have found that it works. In one day both the new Mermaid package and lodash-es fall outside of our 14 day cooldown window, so I think that we should wait for that. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
