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

[armando-navarro]

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 (Prep for AngularFire v21 #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.