|
1 | | -/** |
2 | | - * This is configuration file is used for advanced publishing configurations with Rush. |
3 | | - * More documentation is available on the Rush website: https://rushjs.io |
4 | | - */ |
| 1 | +[{"definitionName":"lockStepVersion","policyName":"vutilMain","version":"0.15.7","nextBump":"patch"}] |
5 | 2 |
|
6 | | -/** |
7 | | - * A list of version policy definitions. A "version policy" is a custom package versioning |
8 | | - * strategy that affects "rush change", "rush version", and "rush publish". The strategy applies |
9 | | - * to a set of projects that are specified using the "versionPolicyName" field in rush.json. |
10 | | - */ |
11 | | -[ |
12 | | - // { |
13 | | - // /** |
14 | | - // * (Required) Indicates the kind of version policy being defined ("lockStepVersion" or "individualVersion"). |
15 | | - // * |
16 | | - // * The "lockStepVersion" mode specifies that the projects will use "lock-step versioning". This |
17 | | - // * strategy is appropriate for a set of packages that act as selectable components of a |
18 | | - // * unified product. The entire set of packages are always published together, and always share |
19 | | - // * the same NPM version number. When the packages depend on other packages in the set, the |
20 | | - // * SemVer range is usually restricted to a single version. |
21 | | - // */ |
22 | | - // "definitionName": "lockStepVersion", |
23 | | - // |
24 | | - // /** |
25 | | - // * (Required) The name that will be used for the "versionPolicyName" field in rush.json. |
26 | | - // * This name is also used command-line parameters such as "--version-policy" |
27 | | - // * and "--to-version-policy". |
28 | | - // */ |
29 | | - // "policyName": "MyBigFramework", |
30 | | - // |
31 | | - // /** |
32 | | - // * (Required) The current version. All packages belonging to the set should have this version |
33 | | - // * in the current branch. When bumping versions, Rush uses this to determine the next version. |
34 | | - // * (The "version" field in package.json is NOT considered.) |
35 | | - // */ |
36 | | - // "version": "1.0.0", |
37 | | - // |
38 | | - // /** |
39 | | - // * (Required) The type of bump that will be performed when publishing the next release. |
40 | | - // * When creating a release branch in Git, this field should be updated according to the |
41 | | - // * type of release. |
42 | | - // * |
43 | | - // * Valid values are: "prerelease", "release", "minor", "patch", "major" |
44 | | - // */ |
45 | | - // "nextBump": "prerelease", |
46 | | - // |
47 | | - // /** |
48 | | - // * (Optional) If specified, all packages in the set share a common CHANGELOG.md file. |
49 | | - // * This file is stored with the specified "main" project, which must be a member of the set. |
50 | | - // * |
51 | | - // * If this field is omitted, then a separate CHANGELOG.md file will be maintained for each |
52 | | - // * package in the set. |
53 | | - // */ |
54 | | - // "mainProject": "my-app", |
55 | | - // |
56 | | - // /** |
57 | | - // * (Optional) If enabled, the "rush change" command will prompt the user for their email address |
58 | | - // * and include it in the JSON change files. If an organization maintains multiple repos, tracking |
59 | | - // * this contact information may be useful for a service that automatically upgrades packages and |
60 | | - // * needs to notify engineers whose change may be responsible for a downstream build break. It might |
61 | | - // * also be useful for crediting contributors. Rush itself does not do anything with the collected |
62 | | - // * email addresses. The default value is "false". |
63 | | - // */ |
64 | | - // // "includeEmailInChangeFile": true |
65 | | - // }, |
66 | | - // |
67 | | - // { |
68 | | - // /** |
69 | | - // * (Required) Indicates the kind of version policy being defined ("lockStepVersion" or "individualVersion"). |
70 | | - // * |
71 | | - // * The "individualVersion" mode specifies that the projects will use "individual versioning". |
72 | | - // * This is the typical NPM model where each package has an independent version number |
73 | | - // * and CHANGELOG.md file. Although a single CI definition is responsible for publishing the |
74 | | - // * packages, they otherwise don't have any special relationship. The version bumping will |
75 | | - // * depend on how developers answer the "rush change" questions for each package that |
76 | | - // * is changed. |
77 | | - // */ |
78 | | - // "definitionName": "individualVersion", |
79 | | - // |
80 | | - // "policyName": "MyRandomLibraries", |
81 | | - // |
82 | | - // /** |
83 | | - // * (Optional) This can be used to enforce that all packages in the set must share a common |
84 | | - // * major version number, e.g. because they are from the same major release branch. |
85 | | - // * It can also be used to discourage people from accidentally making "MAJOR" SemVer changes |
86 | | - // * inappropriately. The minor/patch version parts will be bumped independently according |
87 | | - // * to the types of changes made to each project, according to the "rush change" command. |
88 | | - // */ |
89 | | - // "lockedMajor": 3, |
90 | | - // |
91 | | - // /** |
92 | | - // * (Optional) When publishing is managed by Rush, by default the "rush change" command will |
93 | | - // * request changes for any projects that are modified by a pull request. These change entries |
94 | | - // * will produce a CHANGELOG.md file. If you author your CHANGELOG.md manually or announce updates |
95 | | - // * in some other way, set "exemptFromRushChange" to true to tell "rush change" to ignore the projects |
96 | | - // * belonging to this version policy. |
97 | | - // */ |
98 | | - // "exemptFromRushChange": false, |
99 | | - // |
100 | | - // // "includeEmailInChangeFile": true |
101 | | - // } |
102 | | -] |
0 commit comments