-
Notifications
You must be signed in to change notification settings - Fork 132
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Fix errors in maintainer guide (#847)
- Loading branch information
Showing
1 changed file
with
44 additions
and
27 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -55,6 +55,14 @@ Please follow the [commit message convention](https://oss-generic.github.io/proc | |
|
|
||
| # Doing a Release | ||
|
|
||
| ## Prerequisites for New Maintainers | ||
|
|
||
| Ensure that: | ||
|
|
||
| * You have the rights to push to master branch on [MarkBind's repository](https://github.com/MarkBind/markbind), and also to make new releases. | ||
| * You have the rights on [npm](https://www.npmjs.com/) to make a new release. | ||
| * You need to login to npm on your terminal with `npm adduser` first, before you can publish packages to npm. | ||
|
|
||
| ## Building Vue-Strap | ||
|
|
||
| 1. Ensure that you are on the root directory on vue-strap, then execute: | ||
|
|
@@ -72,7 +80,7 @@ You should see changes in `vue.min.js`, `vue-strap.js.map` and `vue-strap.min.js | |
| 2. Commit the new changes. | ||
|
|
||
| ``` | ||
| $ git commit -m 'Update dist' | ||
| $ git commit -am 'Update dist' | ||
| ``` | ||
|
|
||
| 3. Tag the new commit with the new version number, whereby `XYZ` is the incremented number of the previous release. | ||
|
|
@@ -112,7 +120,27 @@ $ git commit -m 'Update vue-strap version to v2.0.1-markbind.XYZ' | |
|
|
||
| * **Note:** We uniquely do this for each MarkBind release (rather than spontaneously update the vue-strap files for each affected PR), in order to reduce unnecessary merge conflicts. It also makes it easier for the maintainers to vet the changes. | ||
|
|
||
| 2. Rebuild the test files. | ||
| 2. Run `npm version` to increment the version number. Which to increment (`patch`, `minor` or `major`) depends on what PRs are merged for the new version, which means you must know beforehand about the changes. | ||
|
|
||
| * If there are no significant changes, a `patch` is sufficient: | ||
|
|
||
| ``` | ||
| $ npm version patch | ||
| ``` | ||
|
|
||
| * If there are significant changes (e.g. breaking changes, new release), a `minor` release is needed: | ||
|
|
||
| a. Run `npm version minor` as per normal. | ||
|
|
||
| b. Update the version number inside `src/lib/markbind/package-lock.json` and `src/lib/markbind/package.json` manually. This is because `npm version` will not automatically update the numbers from the outside. (Note: You do not have to commit these changes immediately, as we also have to rebuild the test files in the next step anyway.) | ||
|
|
||
| ``` | ||
| $ npm version minor | ||
| ``` | ||
|
|
||
| * We rarely do `major` releases, but if necessary, the steps are the same as the `minor` release (just change `minor` to `major`). | ||
|
|
||
| 3. Rebuild the test files. | ||
|
|
||
| ``` | ||
| # on Unix | ||
|
|
@@ -142,50 +170,35 @@ index 779f279..bb3c602 100644 | |
|
|
||
| However, if there are any extra lines changed, that means that someone screwed up the functional tests, and needs to be fixed accordingly! | ||
|
|
||
| Only when it is fixed do you proceed with the next step of the release procedure. | ||
|
|
||
| 3. Do an `npm version` to increment the version number. Which to increment (`patch`, `minor` or `major`) depends on what PRs are merged for the new version, which means you must know beforehand about the changes. | ||
|
|
||
| * If there are no significant changes, a `patch` is sufficient: | ||
|
|
||
| ``` | ||
| $ npm version patch | ||
| ``` | ||
|
|
||
| * If there are significant changes (e.g. breaking changes, new release), a `minor` release is needed: | ||
|
|
||
| a. Update the version number inside `src/lib/markbind/package-lock.json` and `src/lib/markbind/package.json` manually. This is because `npm version` will not automatically update the numbers from the outside. | ||
|
|
||
| b. Do a `npm version minor` as per normal. | ||
| 4. The changes that you have made in the last two steps need to be combined together with the version commit generated by `npm version`. Therefore, amend the version commit and version tag by doing the following (change `vA.B.C` to the new version's string accordingly). | ||
|
|
||
| ``` | ||
| $ npm version minor | ||
| $ git commit -a --amend --reuse-message vA.B.C | ||
| $ git tag --force vA.B.C # to reassign the tag to the newly amended commit | ||
| ``` | ||
|
|
||
| * We rarely do `major` releases, but if necessary, the steps are the same as the `minor` release (just change `minor` to `major`). | ||
|
|
||
| 4. Push the new commit and version tag generated by `npm` (change `vA.B.C` to the new version's string accordingly). | ||
| 5. Push the new commit and version tag generated by `npm` (change `vA.B.C` to the new version's string accordingly). | ||
|
|
||
| ``` | ||
| $ git push upstream master | ||
| $ git push upstream vA.B.C | ||
| ``` | ||
|
|
||
| 5. Do an `npm publish`. You should receive a notification by `npm` that the publish is successful. | ||
| 6. Run `npm publish`. You should receive a notification by `npm` that the publish is successful. | ||
|
|
||
| ``` | ||
| $ npm publish | ||
| ``` | ||
|
|
||
| 6. If you used `npm link` for your project, ensure that you try the new release on another platform that doesn't use `npm link`, so that we can be sure the end-users can install and use the new version. | ||
| 7. If you used `npm link` for your project, ensure that you try the new release on another platform that doesn't use `npm link`, so that we can be sure the end-users can install and use the new version. | ||
|
|
||
| a. Just do `npm i -g [email protected]` on the different platform and... | ||
|
|
||
| b. ... play around with the new MarkBind version to ensure that it works. | ||
|
|
||
| 7. Ensure that the documentation at markbind.org is deployed correctly. | ||
| 8. Ensure that the documentation at markbind.org is deployed correctly. | ||
|
|
||
| Since #701, the deployment is automated. | ||
| Since [#701](https://github.com/markbind/markbind/pull/701), the deployment is automated. | ||
|
|
||
| However, if it doesn't deploy properly for the release, do the following: | ||
|
|
||
|
|
@@ -195,7 +208,11 @@ $ markbind build | |
| $ markbind deploy | ||
| ``` | ||
|
|
||
| 8. Draft a new release on GitHub. | ||
| 9. Close the [issue milestone on GitHub](https://github.com/MarkBind/markbind/milestones) tied to that version. | ||
|
|
||
| a. Please also create a new milestone for the next iterations. Recommended to have at least two version milestones opened. | ||
|
|
||
| 10. Draft a new release on GitHub. | ||
|
|
||
| a. Go to the Markbind release page at https://github.com/MarkBind/markbind/releases. | ||
|
|
||
|
|
@@ -316,6 +333,6 @@ test: Add diff printing for easier debugging (#632) | |
|
|
||
| f. Click "Publish release". | ||
|
|
||
| 9. Finally, announce the new release on our Slack channel (replace `A.B.C` with the new version). Congrats! | ||
| 11. Finally, announce the new release on our Slack channel (replace `A.B.C` with the new version). Congrats! | ||
|
|
||
| * Published: `npm i -g [email protected]` | ||