[rush] Version Policies

[matteobruni]

Please prefix the issue title with the project name i.e. [rush], [api-extractor] etc.

Is this a feature or a bug?

• [ ] Feature
• [x] Bug

Please describe the actual behavior.

I have this version policies file

[
  {
    "definitionName": "individualVersion",
    "policyName": "1.19-prerelease",
    "version": "1.18.11",
    "nextBump": "prerelease"
  },
  {
    "definitionName": "individualVersion",
    "policyName": "2.2-prerelease",
    "version": "2.1.11",
    "nextBump": "prerelease"
  },
  {
    "definitionName": "individualVersion",
    "policyName": "1.2-prerelease",
    "version": "1.1.11",
    "nextBump": "prerelease"
  },
  {
    "definitionName": "individualVersion",
    "policyName": "1.4-prerelease",
    "version": "1.3.11",
    "nextBump": "prerelease"
  }
]

But when I run rush version it returns me this error

ERROR: JSON validation failed:
[omissis]/tsparticles/common/config/rush/version-policies.json
Error: #/3
Data does not match any schemas from 'oneOf'
Error: #/3/definitionName (The name of version policy definition)
No enum match for: individualVersion
Error: #/3 (Lockstep version policy)
Additional properties not allowed: nextBump,version
Error: #/2
Data does not match any schemas from 'oneOf'
Error: #/2/definitionName (The name of version policy definition)
No enum match for: individualVersion
Error: #/2 (Lockstep version policy)
Additional properties not allowed: nextBump,version
Error: #/1
Data does not match any schemas from 'oneOf'
Error: #/1/definitionName (The name of version policy definition)
No enum match for: individualVersion
Error: #/1 (Lockstep version policy)
Additional properties not allowed: nextBump,version
Error: #/0
Data does not match any schemas from 'oneOf'
Error: #/0/definitionName (The name of version policy definition)
No enum match for: individualVersion
Error: #/0 (Lockstep version policy)
Additional properties not allowed: nextBump,version

What is the expected behavior?

Update all the corresponding packages to the new version, but probably I didn't understand how since the documentation is just a JSON file.

If this is a bug, please provide the tool version, Node.js version, and OS.

• Tool: rush + pnpm
• Tool Version: 5.35.2 + 5.11.1
• Node Version: 14.9.0
  • Is this a LTS version? No
  • Have you tested on a LTS version? No
• OS: macOS Catalina

[iclanton]

When using an individualVersion version policy, version bumps are driven by the bump types defined in the files produced when you run rush change, so the version and nextBump fields shouldn't be there. If you want all of your published projects to be driven by their own changefiles, you don't actually need to specify a version policy. Just make sure you have shouldPublish set to true for those projects in rush.json.

The version and nextBump fields are used when a set of projects are published using lockstep versions (and with the definitionName field set to "lockStepVersion"), which means that a set of projects are all published together with the same version, regardless of whether any individual projects has changes.

If you want your projects to be released with a prerelease version, you need to change to a lockStepVersion version policy. Projects' CHANGELOG.md files will still get updates from the changefiles produced by rush change, but the next version will be a prerelease. Keep in mind that if you don't want all of your projects released with the same prerelease version, you need to run rush version or rush publish for each of the version policies. This is an unfortunate limitation on how prereleases work. We've wanted to redesign how versioning and publishing work in an upcoming major version of Rush, but our team hasn't had time yet. Any suggestions on how this could make more sense are more than welcome.

[matteobruni]

Thanks, so I need to run rush change before rush version right?

I don't have clear the commands flow. I have packages with different versions but they will be released together so the steps they make are the same. I'm trying to migrate from lerna to rush but the version/publish flow is what I am missing.

Is it lockStepVersion suitable for different versions with the same steps or I was right with individualVersion?

[iclanton]

Thanks, so I need to run rush change before rush version right?

Correct. The intended flow is:

1. Fork the repo's main/master branch into a feature branch
2. Make and commit changes
3. Run rush change and to generate a changefile describing the changes.
4. Commit the changefile(s)
5. Merge the feature branch back into the main/master branch

6. Run rush version and/or rush publish to collapse the changefiles into projects' CHANGELOG.md files and, for non-lockstepped projects, bump project versions by the largest bump in the changefiles present for each project

   Is it lockStepVersion suitable for different versions with the same steps or I was right with individualVersion?

lockStepVersion is intended for a set of projects that are released together with the same version. For example, @microsoft/rush and @microsoft/rush-lib are always bumped together and always have the same version. If your projects are versioned separately, you probably want individualVersion (or you can just set "shouldPublish" to true for those projects in rush.json and not specify any version policy at all). However I don't believe, the prerelease version bump type isn't available for individually versioned projects. If you specifically want prereleases (i.e. - versions that look like 1.2.3-prerelase.1), you may have to use a lockStepVersion.

WRT how publishing should actually kicked off, take a look at the publishing pipeline definition for this repo here

[genepaul]

I have been struggling with this as well. I have a set of currently independently versioned but related libraries that I'd like to consolidate into a monorepo for easier maintenance. For one of those libraries, it currently has a prerelease process where I use a branch to maintain a beta version. When versions get bumped on that branch, I get v5.0.0-beta.1, v5.0.0-beta.2, etc. I'm trying to pull that into a rush monorepo and figure out how it would handle the version policy. I tried to define a lockStepVersions version policy for it:

{
    "definitionName": "lockStepVersion",
    "policyName": "ComponentLibraryPrerelease",
    "version": "5.0.0-beta.11", // setting this to the current beta version of the library when I pull it in
    "nextBump": "prerelease",
    "mainProject": "my-component-library"
  }

I have this project config for that in my rush.json:

{
      "packageName": "my-component-library",
      "projectFolder": "components/component-library",
      "reviewCategory": "production",
      "shouldPublish": true
    }

I can't seem to figure out what combination of rush version or rush publish will properly increment my library to beta.12 based on a dummy change I made. I have a change file:

{
  "changes": [
    {
      "packageName": "my-component-library",
      "comment": "fix accordion background color on hover",
      "type": "patch"
    }
  ],
  "packageName": "my-component-library"
}

I've tried: rush version --version-policy ComponentLibraryPrerelease --bump but that bumps the version to 5.0.0 in the package json. It is not at all clear from the documentation how I would manage a prerelease pipeline for a library like this. Any help is greatly appreciated.