meta: add support for alpha prerelease tag

[aduh95]

Refs: nodejs/Release#1154

There would be more work needed on the tooling (i.e. NCU), but let's see first if we have consensus on the process.

[nodejs-github-bot]

Review requested:

• @nodejs/tsc

[Renegade334]

So, under this schema, alpha versions would be named A.B.C-alpha.D.E.F? Would it not make more sense to have a single alpha counter?

[aduh95]

Would it not make more sense to have a single alpha counter?

Why? What would be the upside?

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 89.70%. Comparing base (18f938d) to head (fa0ef1a).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #63135      +/-   ##
==========================================
+ Coverage   89.67%   89.70%   +0.02%     
==========================================
  Files         712      712              
  Lines      221251   221251              
  Branches    42393    42390       -3     
==========================================
+ Hits       198413   198464      +51     
+ Misses      14681    14622      -59     
- Partials     8157     8165       +8     

see 50 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[RafaelGSS]

I wouldn't include MINOR or PATCH for Alpha. Possibly, we should only have:

#define NODE_IS_ALPHA_RELEASE 0
#define NODE_ALPHA_MAJOR_VERSION 0

and increment NODE_ALPHA_MAJOR_VERSION on every release until LTS.

[aduh95]

Why? What would be the upside?

[RafaelGSS]

It's simpler. We won't need to maintain a guarantee that v27.0.0-alpha.2 won't break v27.0.0-alpha.1 users, as it would need to be guaranteed if we decide to ship v27.0.0-alpha.1.1.0 on top of v27.0.0-alpha.1.0.0

[RafaelGSS]

Note that starting simpler would allow us to go to your suggested model if we feel the need. The opposite is not true.

[aduh95]

The opposite is not true.

I don't think so, either we need to pick a system and stick to it, either we can change if we feel the need. I don't see why we could go from -alpha.1 to -alpha.1.0.1 and not from -alpha.1.0.1 to -alpha.2

[Renegade334]

If we seek to provide semver semantics within the alpha phase, then we've just re-invented the old release model IMO. May need discussion, but I think it makes more sense to have the alpha versioning be linear, with no undertaking to provide any non-breakage guarantees between any two alpha builds. (I imagine that would make things significantly more straightforward for releasers as well!)

[trivikr]

I personally prefer <prerelease>.<num> since it's shorter and widely adopted by ecosystem, including existing Node.js rc versions.
I'd posted examples in nodejs/Release#1154 (comment)

[aduh95]

then we've just re-invented the old release model IMO

Not at all, the key difference is that we plan on releasing semver-major changes during the alpha period – which we would not do with the old release model.
The blog post announcing the new schedule explicitly says "The Alpha channel fills the early-testing role that odd-numbered releases once served", so it's definitely a goal to stick to the old release schedule.

I imagine that would make things significantly more straightforward for releasers as well!

I don't really see why that would be the case, adding the semver-• label on PRs is not done by releasers – and we want to add those labels regardless how we name the prereleases.

no undertaking to provide any non-breakage guarantees between any two alpha builds

We make our own rules, we don't have to guarantee anything. The goal is to document (via the version number) when there are breakages, and when we think there are none.

[marco-ippolito]

On one side, we already know which commits are semver major, patch and minor so the versioning should not add too much complexity. On the other side you always increment by one regardless, so it's a bit easier. I would prefer the full semver since provides more information, and shouldnt add too much churn

[panva]

I am too unfamiliar with the release and changelog generation process so excuse this possibly silly note.

• we should probably have an alpha-specific changelog_v*_alpha.md file which contains our regular changelog output that we're using today
• at the time of a stable major the non-alpha changelog we produce is the organized cumulative changelog with the last stable release as a starting point (not the last alpha)

Is that what this PR already describes or is it in any way problematic? The point is that a release log for a stable major release isn't a diff from the last alpha.