waveterm/homebrew-cask
0
0
Fork 0
mirror of https://github.com/wavetermdev/homebrew-cask.git synced 2026-08-05 13:43:24 -07:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #2712 from rolandwalker/doc_releasing_updates

Browse Source 
doc: further update RELEASING.md
This commit is contained in:
Roland Walker
2014-01-31 09:34:50 -08:00
parent 9b54dc9c0f 75e7684a7f
commit 74cbb13d2c
1 changed files with 16 additions and 13 deletions
Download Patch File Download Diff File Expand all files Collapse all files
RELEASING.md
+16 -13
View File
@@ -8,8 +8,8 @@ We attempt to follow [Semantic Versioning](http://semver.org/) as much as
possible.
Since we are still pre-1.0, this essentially means that we bump the PATCH
number when we fix bugs, and we bump the MINOR number when we add stuff. Pretty
simple.
number when we fix bugs, and we bump the MINOR number when we add features.
Pretty simple.
The script `developer/bin/get_release_tag` can tell you the latest release
tag that exists and/or calculate the proposed next release tag. Docs are at
@@ -23,22 +23,23 @@ down than floating in a brain somewhere.
1. Do a `git log` since the last release to see what changed. You can scope it to
`lib` to just pick up code changes and filter out Casks noise. Like this:
```bash
git log $(developer/bin/get_release_tag)..HEAD lib
git log "$(developer/bin/get_release_tag)"..HEAD lib
```
2. Decide whether to bump the minor or patch fields in the next tag, based on
whether or not features were added. Run the shell command
```bash
new_tag=$(developer/bin/get_release_tag -next) # or -next -patch
new_tag="$(developer/bin/get_release_tag -next)"; echo "$new_tag" # or use -next -patch
```
and make sure the value in `$new_tag` is what you want.
3. Optionally run `developer/bin/project_stats release` for overall release stats.
4. Bump the `VERSION` string which is stored in the file `lib/cask/version.rb`.
It should match `$new_tag`.
5. Populate the CHANGELOG with a new section for the release you are creating.
It should match `$new_tag`, EXCEPT that the leading `v` character should be
removed fom the version number in the Ruby code.
5. Populate `CHANGELOG.md` with a new section for the release you are creating.
Follow the patterns used elsewhere in the file.
6. Make a commit containing the CHANGELOG and version-bump. Like this:
6. Make a commit containing `CHANGELOG.md` and `lib/cask/version.rb`. Like this:
```bash
git add CHANGELOG lib/cask/version.rb
git add CHANGELOG.md lib/cask/version.rb
git commit -m "cut $new_tag"
```
7. Tag that commit, ensuring that you provide a message so we get an annotated
@@ -50,16 +51,18 @@ down than floating in a brain somewhere.
```bash
git push --follow-tags
```
9. Unset `$new_tag`, you don't need it anymore.
9. Unset `$new_tag`; you don't need it anymore.
```bash
unset new_tag
```
10. Open your browser to <https://github.com/phinze/homebrew-cask/releases> .
Then click the link for your newly pushed tag. Click the "Edit Tag" button in
Then click the link for your newly-pushed tag. Click the "Edit Tag" button in
the top right corner of that page.
11. Paste the markdown summary from the CHANGELOG in the body of the release and
click "Publish Release".
12. Rejoice! Have a :cookie:.
11. Paste the markdown summary from `CHANGELOG.md` into the textarea on that page.
The `## <version number>` heading line from the markdown should not be included.
The `Release title` field on the GitHub web form may be left blank.
12. Click "Publish Release".
13. Rejoice! Have a :cookie:.
## Things to Consider