You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: CONTRIBUTING.md
+42-42Lines changed: 42 additions & 42 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -31,73 +31,73 @@ accepted.
31
31
32
32
1. Go to the **main** branch and ensure it is up to date with the remote:
33
33
34
-
```bash
35
-
git checkout main
36
-
git pull
37
-
```
34
+
```bash
35
+
git checkout main
36
+
git pull
37
+
```
38
38
39
-
2. Run the script that will generate the CHANGELOG for you:
39
+
1. Run the script that will generate the CHANGELOG for you:
40
40
41
-
```bash
42
-
sh tool/release_ready.sh <new-version>
43
-
```
41
+
```bash
42
+
sh tool/release_ready.sh <new-version>
43
+
```
44
44
45
-
**Note 💡** : You should follow semantic versioning and bump according to the changes the new version makes.
45
+
**Note 💡**: You should follow semantic versioning and bump according to the changes the new version makes.
46
46
47
-
`<new-version>`: The version of this new extension release, for example: 0.2.1
47
+
`<new-version>`: The version of this new extension release, for example: 0.2.1
48
48
49
-
The release_ready script will:
49
+
The release_ready script will:
50
50
51
-
- Create a new branch just for this release and checkout to it.
52
-
- Automatically update the CHANGELOG file with the associated changes.
51
+
- Create a new branch just for this release and checkout to it.
52
+
- Automatically update the CHANGELOG file with the associated changes.
53
53
54
-
3. Manually remove the *(deps-dev)* scope or other entries of the conventional commits entries in the CHANGELOG
55
-
4. Add the changes and commit with the commit message that the *release_ready* script outputted.
56
-
5. Raise a Pull Request, the title should be the same as the commit message outputted by the *release_ready* script.
57
-
6. When the Pull Request is merged, tag a new release to the commit. When adding the tag ensure:
54
+
1. Manually remove the *(deps-dev)* scope or other entries of the conventional commits entries in the CHANGELOG
55
+
1. Add the changes and commit with the commit message that the *release_ready* script outputted.
56
+
1. Raise a Pull Request, the title should be the same as the commit message outputted by the *release_ready* script.
57
+
1. When the Pull Request is merged, tag a new release to the commit. When adding the tag ensure:
58
58
- The tag is pointing to the commit that you recently merged.
59
59
- The title of the tag should be v<new-version>
60
60
- The title of the release should be v<new-version>
61
61
- The description should be a raw copy of the CHANGELOG’s file version’s body you recently crafted (without the version header). If in doubt, see the other released tags as an example.
62
-
7. After the release is tagged the new changes will be available by the the following syntax:
62
+
1. After the release is tagged the new changes will be available by the the following syntax:
63
63
64
-
```yaml
65
-
VeryGoodOpenSource/..@v<new-version>
66
-
```
64
+
```yaml
65
+
VeryGoodOpenSource/..@v<new-version>
66
+
```
67
67
68
-
Where:
68
+
Where:
69
69
70
-
-`<new-version>`: The version of this new workflow or action, for example: 0.2.1
71
-
8. Go to the **main** branch and ensure it is up to date with the remote:
70
+
- `<new-version>`: The version of this new workflow or action, for example: 0.2.1
72
71
73
-
```yaml
74
-
git checkout main
75
-
git pull
76
-
```
72
+
1. Go to the **main** branch and ensure it is up to date with the remote:
77
73
78
-
9. Retag the major release.
74
+
```yaml
75
+
git checkout main
76
+
git pull
77
+
```
79
78
80
-
For the Workflow or Action to be updated for those users using the `@<major-version` syntax we will require to retag the major release.
79
+
1. Retag the major release.
81
80
82
-
```yaml
83
-
sh tool/retag_v<major-version>.sh <new-version>
84
-
```
81
+
For the Workflow or Action to be updated for those users using the `@<major-version` syntax we will require to retag the major release.
85
82
86
-
Where:
83
+
```yaml
84
+
sh tool/retag_v<major-version>.sh <new-version>
85
+
```
87
86
88
-
-`<major-version>`: Is the major version of the release, for example in 2.16.3 the major version is 2. For more information see the [semantic versioning documentation](https://semver.org/).
89
-
-`<new-version>`: The version of this new workflow or action, for example: 0.2.1.
87
+
Where:
90
88
89
+
- `<major-version>`: Is the major version of the release, forexamplein 2.16.3 the major version is 2. For more information see the [semantic versioning documentation](https://semver.org/).
90
+
- `<new-version>`: The version of this new workflow or action, for example: 0.2.1.
91
91
92
-
If your change is a breaking change and requires a new major release you should update the name of the retag script and its `v<major-version>` instances.
92
+
If your change is a breaking change and requires a new major release you should update the name of the retag script and its `v<major-version>` instances.
93
93
94
-
10. After the retag the new changes will be available by the the following syntax:
94
+
1. After the retag the new changes will be available by the the following syntax:
95
95
96
-
```yaml
97
-
VeryGoodOpenSource/..@v<major-version>
98
-
```
96
+
```yaml
97
+
VeryGoodOpenSource/..@v<major-version>
98
+
```
99
99
100
-
Where: `<major-version>`: Is the major version of the release, for example in 2.16.3 the major version is 2. For more information see the [semantic versioning documentation](https://semver.org/).
100
+
Where: `<major-version>`: Is the major version of the release, forexamplein 2.16.3 the major version is 2. For more information see the [semantic versioning documentation](https://semver.org/).
0 commit comments