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
Build: Add audit script for reviewing changes to build artifacts
* Automate the workflow I have been using for auditing the release
artefacts prior to publication. This protects against mistakes
or other accidents that may have gone unnnoticed (e.g. in how
Rollup is configured, or what files we embed and distribute),
as well as against any compromise or other malicious activity
in the build chain (in one of the many unaudited dev dependencies
we use from npm, or elsewhere).
* No longer recommend `npm run serve`. This can't easily be run
in an isolated environment as it needs to expose a port. Unlike
other build scripts, this involves unaudited dev dependencies.
Recommend use of the built-in and dependency-free HTTP server
from Python or PHP instead.
* Minor improvements throughout RELEASE.md, especially to simplify
and consolidate related steps, and make the numbering continuous
throughout the page (10 steps total, more or less).
[](https://gitter.im/qunitjs/qunit?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge)
Copy file name to clipboardExpand all lines: RELEASE.md
+58-48Lines changed: 58 additions & 48 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,28 +1,30 @@
1
-
# Release Process
1
+
# Release process
2
2
3
-
This guide walks you through a QUnit release.
3
+
This guide walks you through the QUnit release.
4
4
5
5
⚠️ **WARNING** ⚠️
6
6
7
-
> Before attempting the process below, make sure you have:
7
+
> Before starting, make sure you have:
8
8
>
9
9
> ***Permission to publish to the jQuery CDN** via [jquery/codeorigin.jquery.com](https://github.com/jquery/codeorigin.jquery.com).
10
10
> * Permission to publish releases to npm for the [`qunit`](https://www.npmjs.com/package/qunit) npm package.
11
11
> * Permission to publish the website via [qunitjs/qunit.com](https://github.com/qunitjs/qunitjs.com).
12
-
13
-
Prerequisites:
14
-
15
-
* Node.js 12, or later.
16
-
* Git 2.11, or later.
12
+
>
13
+
> System prerequisites:
14
+
>
15
+
> * Node.js 12, or later.
16
+
> * Git 2.11, or later.
17
17
18
18
1. Ensure that all changes for this release have been merged into the main branch. For patch releases, try landing any other bug fixes; for minor releases, ensure new features have been documented and tested. Major releases likely have their own checklist.
19
19
20
-
2.Ensure that you have a prestine copy of the canonical repo (not a fork), and create a local `release` branch:
21
-
*Run `git remote -v` and verify the following:
20
+
2.Create a local `release` branch, and ensure it is up-to-date:
21
+
*Verify that the canonical repository is cloned (not a fork):
Run the tests in various real browsers as well, either locally or via [BrowserStack](https://www.browserstack.com/):
36
+
Run the tests in various real browsers, either locally or via [BrowserStack](https://www.browserstack.com/):
35
37
```
36
-
npm run serve
37
-
open 'http://localhost:4000/test/'
38
+
python3 -m http.server 4000
39
+
# or:
40
+
# php -S localhost:4000
41
+
42
+
open http://localhost:4000/test/
38
43
```
39
44
40
45
4. Create and push the release preparation commit:
@@ -43,68 +48,76 @@ Prerequisites:
43
48
```
44
49
node build/prep-release.js @VERSION
45
50
```
46
-
* Review the difference in the `AUTHORS.txt` file. If you see duplicate entries proposed, then use the `.mailmap` file to normamlize those entries to a canonical name or e-mail address, and then re-run the above command.
47
-
* Edit `History.md` and remove any "Build", "Tests" or other commits not relevant to end-users.
48
-
2. Commit all of the above with the following message (replace `@VERSION` with the release version):
51
+
* Use `git add -p` to review the changes.
52
+
* In `AUTHORS.txt`, if you see duplicate entries, then use the `.mailmap` file to normalize them to a canonical name and e-mail address, and then re-run the above command.
53
+
* Edit `History.md` to remove change not relevant to end-users (e.g. changes relating to tests, build, internal refactoring, doc fixes, etc.).
54
+
2. Commit the above changes with the following message (replace `@VERSION` with the release version):
49
55
```
50
56
Build: Prepare @VERSION release
51
57
```
52
-
3. Push your `release` branch to GitHub.
53
-
4. Create a pull request, approve it, and merge it once Travis CI is passing.
58
+
3. Push the `release` branch to GitHub.
59
+
4. Create a pull request, and merge it once Travis CI is passing.
54
60
55
61
## Performing the release
56
62
57
-
1. Create a local `release` branch, and ensure you're working on the canonical repo (not a fork):
63
+
5. Create a local `release` branch, and ensure it is up-to-date:
2. Ensure that the latest commit is your release preparation commit:
72
+
* Verify that the latest commit is your release preparation commit:
68
73
```
69
74
git show
70
75
# Build: Prepare x.y.z release
71
76
# …
72
77
```
73
78
74
-
3. Set the release version for npm and Bower metadata, by running the below command (replace `@VERSION` with the release version):
79
+
6. Make changes for the release commit:
80
+
* Set the release version for npm and Bower metadata (replace `@VERSION` with the release version):
75
81
```
76
82
node build/set-release.js @VERSION
77
83
```
78
-
This script will edit `package.json` and `bower.json` for you. It does not require any credentials or permissions, apart from read-write in the project directory.
84
+
This script will edit `package.json` and `bower.json`. It does not need any credentials or permissions, apart from read-write in the project directory.
6. Create the release commit, tag it, and push the tag to GitHub (replace `@VERSION` with the release version).<br>⚠️ Do not commit or push release artifacts to the main branch!
97
+
* Review the changes to the package and library files, compared to the previous release.
98
+
```
99
+
node build/review-package.js @LAST_VERSION
100
+
101
+
# … reviews package.json, qunit.js, and qunit.css
102
+
```
103
+
104
+
7. Commit and publish the release to GitHub.<br>⚠️ Do not push to the main branch!
92
105
```
93
106
git add package.json bower.json qunit/
94
107
git commit -m "Release @VERSION"
95
108
git tag -s "@VERSION" -m "Release @VERSION"
96
109
git push --tags
97
110
```
98
111
99
-
7. Verify that Bower sees the release, by running `bower info qunit` and checking that the latest
112
+
8. Verify that Bower sees the release, by running `bower info qunit` and checking that the latest
100
113
version is indeed the version we just published.
101
114
102
-
8. Publish the release to npm:
103
-
* Use `git status` to confirm once more that your checkout is clean apart from the release artifacts in `qunit/`.
115
+
9. Publish the release to npm:
116
+
* Use `git status` to confirm once more that you have a clean working copy, apart from release artifacts in `qunit/`.
104
117
* Run `npm publish`, this will bundle the current directory and publish it to npm with the name and version specified in `package.json`.
105
118
* Verify that the release is displayed at <https://www.npmjs.com/package/qunit>.
106
119
107
-
9. Publish the release to the jQuery CDN:
120
+
10. Publish the release to the jQuery CDN:
108
121
* Prepare the commit locally:
109
122
```
110
123
node build/auth-cdn-commit.js real @VERSION
@@ -117,34 +130,31 @@ Prerequisites:
117
130
# …
118
131
git push
119
132
```
120
-
* Verify via <https://code.jquery.com/qunit/qunit-x.y.z.js>
133
+
* Verify that the release is listed at <https://code.jquery.com/qunit/> and accessible via <https://code.jquery.com/qunit/qunit-x.y.z.js>
121
134
122
135
## Updating the website
123
136
124
-
Once you have successfully published the new release, we need to update the website.
137
+
After the release is published, we need to update the website.
Check out the main branch of the [qunitjs/qunitjs.com](https://github.com/qunitjs/qunitjs.com) repository, and ensure it is clean and up-to-date. Update release links and demos to use the version we just released, using this script:
128
140
129
-
Checkout the latest `master` branch of the website repo.
141
+
```
142
+
qunitjs.com$ node build/set-version.js <version>
143
+
```
130
144
131
-
Do a find and replace of the previous version number and insert the new version number. Commit these changes with the following message:
145
+
Stage the changes it made, and commit with the following message:
132
146
133
-
All: Update url and version to @VERSION
147
+
```
148
+
All: Update url and version to <version>
149
+
```
134
150
135
-
Then push the commit:
136
-
137
-
git push
138
-
139
-
Check the website in a few minutes after a build completes to verify it is updated.
151
+
Push the commit, and check the website in a few minutes to verify the change ([deployment log](https://github.com/qunitjs/qunitjs.com/deployments/activity_log?environment=github-pages)).
140
152
141
153
## Final steps
142
154
143
155
You're almost there! Make sure you update [GitHub releases](https://github.com/qunitjs/qunit/releases) using the changelog from `History.md`.
144
156
145
-
Finally, make an announcement on the [@qunitjs](https://twitter.com/qunitjs) Twitter account. Mention highlights of the release if possible and feel free to include a second tweet if needed, but be sure to include a link to the release page like so:
146
-
147
-
Released @VERSION: https://github.com/qunitjs/qunit/releases/tag/x.y.z
157
+
Finally, make an announcement on the [@qunitjs](https://twitter.com/qunitjs) Twitter account. Mention highlights of the release if possible, andinclude a link to the release page.
148
158
149
159
That's it! If you made it this far, congratulations you have successfully released a version of QUnit!
0 commit comments