Canary builds are named after the release candidate, so npm ranks them above it

Inizia dal package.json root e da tools/build.sh, quindi segui il modo in cui vengono selezionate le versioni per le build Canary e per le build di release contrassegnate con un tag. Verifica le versioni dei pacchetti risultanti rispetto all’ordinamento semver di npm, assicurandoti che le Canary siano classificate al di sotto della release candidate, mentre le release contrassegnate con un tag mantengano le relative versioni del tag.

ng add @angular/fire@next and ng update @angular/fire@next install a canary, not the release candidate.

When #3674 was merged, 21.0.0-rc.0 was put in package.json, breaking with this repo's previous patterns. #3751 continued this break with 21.0.0-rc.1.

#3709 mitigated the symptom for ng add by writing the exact installed version into the user's package.json. But going back to the old pattern would simplify things further.

Details

• The root package.json version field holds 21.0.0-rc.1, and tools/build.sh specifies each canary by appending -canary.<short sha> to that field.
  • Every merge to main therefore publishes 21.0.0-rc.1-canary.<sha>, which semver ranks above 21.0.0-rc.1, because the middle identifier parses as the text 1-canary and text outranks a number.
• ng add @angular/fire@next installs a canary, not the release candidate. The Angular CLI resolves the tag, then writes the range ^21.0.0-rc.1, and npm resolves that to 21.0.0-rc.1-canary.95b3de1.
• ng update @angular/fire@next does the same, and unlike ng add it leaves a range in package.json rather than an exact version, so the app can drift again on any later install.
• The version field is not what a tagged release publishes. tools/build.sh takes a tagged release's version from the tag name.
  • At the 19.0.0-rc.5 tag the version field in package.json read 19.0.0, yet the release published to npm from that tag is 19.0.0-rc.5.
  • At the 20.0.1 tag the field read 20.0.0 and the release published to npm is 20.0.1.
• Releases through v20 named canaries after the release itself, for example 19.0.0-canary.<sha>, which ranks below every 19.0.0-rc.N.
  • The release-candidate string first entered the version field in the v21 preparation commit (#3674).

Scope

Build and packaging. It does not remove the 25 canary builds already published on the 21 line, which keep outranking 21.0.0-rc.1 until 21.0.0 ships.