[rush] How to version bump and publish prerelease on ci?

[icy0307]

Summary

Hey , thanks for the awesome library! I'm trying to build a workflow to publish prerelease packages for my team. Let's say we have a package A, which depends on package b, with different individual version. When publish a prerelease version , like [email protected], hope [email protected] get published as well.

Repro steps

Expected result: Be able to use rush bump for prerelease version, without lockstep Actual result:

Details

My questions are:

1. Should I use rush version bump? How can I bump prerelease version without modifying nextBump in version-policies.json ? (Don't want to change every versionPolicyName in rush.json manually before merged to master ). Why policy with 'nextBump' must be 'lockStep'? There is a --override-bump flag in rush version bump, should I use this? I tried this flag, but nothing happened?
2. Is rush change always necessary？ After all it is a prerelease branch for test, which changelog might not be accurate yet. And I found that version --bump won't do anything if change file's type is none
3. Should I use --prerelease-name flag in rush publish? the version seems not bump properly. If Modifying nextBump is the only way, How could I make it less cumbersome in CI workflow? @Pete Gonzalez

Standard questions

Please answer these questions to help us investigate your issue more quickly:

Question	Answer
@microsoft/rush globally installed version?
rushVersion from rush.json?	5.54.0
useWorkspaces from rush.json?	false
Operating system?	macos 12.0.1
Would you consider contributing a PR?	Yesnod
Node.js version (node -v)?	14.15.0

[iclanton]

1. Those options indeed only work for lockstep versions. This is because applying a prerelease to a set of packages that aren't locked to the same version produces behavior that is difficult to rationalize. Versioning is very complicated and we've talked a number of times over the past few years about redesigning it. Can you outline how your scenario would work in some greater detail? In your example ("When publish a prerelease version , like [email protected], hope [email protected] get published as well."), what were the versions of packages b and a before applying the prerelease? If the versions were 1.0.0 and 1.2.0 respectively before, the prerelease 1.0.0-beta-1 for package b doesn't make sense because that is an older version than 1.0.0, so you've published a downgrade.
2. In order to know what the bump you're publishing a prerelease for, you'd need a changefile describing the kind of bump.
3. I think you do need a nextBump specified. Like I said, publishing deserves a redesign, and this is one of the things that should be considered during that redesign. We just need a detailed spec first.

[icy0307]

Yes, I made a mistake about the prerelease versions. @iclanton The repos originally looks like this:

packages: [email protected] [email protected] package b depends on package a, as "a:^1.0.0" They share same version policy, with "individualVersion". A host app depend on package a.

Scenario 1: a is modified for some experimental reasons, [email protected] should be published. And according to npm semver calculator, [email protected] will not match a:^1.0.0. In order to test this behavior in host app, b has to upgrade its dependency as a:^1.0.1-beta.0, and publish itself as [email protected] All the packages in the dependency's graph that influenced by this should update its package.json and publish a prerelease version. So rush bump would be perfect for this scenario, if prerelease is supported for individualVersion.

I understand it is not an easy task cause each package may describe their prerelease version in different ways. Like in the previous scenario, if [email protected] is published, then [email protected] should be published.

[uni-zheng]

Same confusion.

[raihle]

A bit late to the party, and I'm not exactly recommending the approach, but we are currently doing this in our PRs:

rush publish --prerelease-name <PR number>-<CICD "run" ID> --publish --partial-prerelease --apply

We don't use version policies: the "old old" publishing flow is very similar to individual versioning, but also supports pre-releases. Contributors do have to run rush change before pushing.

This will bump to the "target" version according to change-files, and append the prerelease name. Packages that have no changes of their own get patch version updates (still with the prerelease suffix).

It ends up publishing a bit too much - not just "packages that would be published and their (transitive) dependents" (which is what I would expect), but also (transitive) dependents of packages with "none"-type changes. But it catches everything we want to publish, and making sure that the others are built "just in case" isn't too bad since we have remote build cache.