metasploit-version 0.1.2-java → 0.1.3-java
Sign up to get free protection for your applications and to get access to all the features.
- checksums.yaml +4 -4
- data/.rspec +2 -0
- data/.travis.yml +10 -3
- data/CHANGELOG.md +6 -0
- data/CONTRIBUTING.md +10 -44
- data/Gemfile +12 -8
- data/RELEASING.md +86 -0
- data/Rakefile +5 -4
- data/UPGRADING.md +1 -0
- data/app/templates/.rspec.tt +2 -0
- data/app/templates/CHANGELOG.md.tt +18 -0
- data/app/templates/CONTRIBUTING.md.tt +122 -0
- data/app/templates/RELEASING.md.tt +99 -0
- data/app/templates/Rakefile.tt +7 -0
- data/app/templates/UPGRADING.md.tt +1 -0
- data/app/templates/lib/versioned/version.rb.tt +64 -0
- data/app/templates/spec/lib/versioned/version_spec.rb.tt +3 -0
- data/app/templates/spec/lib/versioned_spec.rb.tt +4 -0
- data/app/templates/spec/spec_helper.rb.tt +76 -0
- data/bin/metasploit-version +12 -0
- data/config/cucumber.yml +3 -0
- data/features/metasploit-version/install/add_development_dependency.feature +68 -0
- data/features/metasploit-version/install/bundle_install.feature +24 -0
- data/features/metasploit-version/install/changelog.feature +29 -0
- data/features/metasploit-version/install/conflict.feature +45 -0
- data/features/metasploit-version/install/contributing.feature +139 -0
- data/features/metasploit-version/install/namespace_spec/gem_version_constant.feature +154 -0
- data/features/metasploit-version/install/namespace_spec/namespace.feature +33 -0
- data/features/metasploit-version/install/namespace_spec/version_constant.feature +179 -0
- data/features/metasploit-version/install/rake_spec.feature +27 -0
- data/features/metasploit-version/install/releasing/ruby_versions.feature +50 -0
- data/features/metasploit-version/install/releasing/versioning.feature +138 -0
- data/features/metasploit-version/install/steps/gemspec_steps.rb +19 -0
- data/features/metasploit-version/install/upgrading.feature +19 -0
- data/features/metasploit-version/install/version.feature +11 -0
- data/features/metasploit-version/install/version/namespace.feature +157 -0
- data/features/metasploit-version/install/version/prerelease.feature +154 -0
- data/features/metasploit-version/install/version_spec/namespace.feature +32 -0
- data/features/metasploit-version/install/version_spec/testing/branch_from_master.feature +40 -0
- data/features/metasploit-version/install/version_spec/testing/branching_from_branch.feature +161 -0
- data/features/metasploit-version/install/version_spec/testing/merge_branch_to_master.feature +97 -0
- data/features/{shared/examples/metasploit/version/version_module/prerelease/git/step_definitions → step_definitions}/environment_variable_steps.rb +1 -1
- data/features/{shared/examples/metasploit/version/version_module/prerelease/git/step_definitions → step_definitions}/git_steps.rb +11 -3
- data/features/support/env.rb +15 -11
- data/lib/metasploit/version.rb +1 -0
- data/lib/metasploit/version/cli.rb +321 -0
- data/lib/metasploit/version/version.rb +2 -2
- data/metasploit-version.gemspec +2 -2
- data/spec/lib/metasploit/version/branch_spec.rb +1 -3
- data/spec/lib/metasploit/version/cli_spec.rb +514 -0
- data/spec/lib/metasploit/version/version_spec.rb +2 -4
- data/spec/lib/metasploit/version_spec.rb +2 -4
- data/spec/spec_helper.rb +63 -1
- data/spec/support/shared/examples/metasploit/version/version_module.rb +3 -1
- metadata +81 -7
checksums.yaml
CHANGED
@@ -1,7 +1,7 @@
|
|
1
1
|
---
|
2
2
|
SHA1:
|
3
|
-
metadata.gz:
|
4
|
-
data.tar.gz:
|
3
|
+
metadata.gz: d1a326e7c7a8a2d4454151ac070b3eb0f2825857
|
4
|
+
data.tar.gz: ee32dabd353782ccebc8168fc1e56dd2b08f8f5d
|
5
5
|
SHA512:
|
6
|
-
metadata.gz:
|
7
|
-
data.tar.gz:
|
6
|
+
metadata.gz: 8b0a601611790bff15b8a8caee4cdc3e1af3a9a5cbfb3234dd2bf69c9ef009a805190634cdd478b0cd6d56b328700b5e6efb51cf901f2b8f1b6d5c5f9da996ca
|
7
|
+
data.tar.gz: bfacb013d64b6cb4bbd5adf327656bda62e0c14e9f65835c6abad73331199211836f7ca67ad24fa512fff985359e351846fa383e115c6b578f6214318323c61d
|
data/.rspec
ADDED
data/.travis.yml
CHANGED
@@ -9,18 +9,25 @@ matrix:
|
|
9
9
|
allow_failures:
|
10
10
|
- rvm: ruby-head
|
11
11
|
fast_finish: true
|
12
|
-
# documentation coverage is not influenced by ruby version, but the dependencies differ for MRI and JRuby, so
|
13
|
-
# rake yard for both.
|
14
12
|
include:
|
13
|
+
# documentation coverage is not influenced by ruby version, but the dependencies differ for MRI and JRuby, so
|
14
|
+
# rake yard for both.
|
15
15
|
- rvm: 2.1
|
16
16
|
env: RAKE_TASK=yard
|
17
17
|
- rvm: jruby
|
18
18
|
env: RAKE_TASK=yard
|
19
|
+
# Advised to turn off JIT with RBXOPT-Xint by @rubinius on twiiter
|
20
|
+
# @see https://twitter.com/rubinius/status/518563456363274240
|
21
|
+
# @see https://twitter.com/rubinius/status/518563552953917440
|
22
|
+
- rvm: rbx-2.2
|
23
|
+
env: RAKE_TASK=cucumber RBXOPT=-Xint
|
24
|
+
- rvm: rbx-2.2
|
25
|
+
env: RAKE_TASK=spec RBXOPT=-Xint
|
26
|
+
|
19
27
|
rvm:
|
20
28
|
- 1.9.3
|
21
29
|
- 2.0
|
22
30
|
- 2.1
|
23
31
|
- ruby-head
|
24
32
|
- jruby
|
25
|
-
- rbx-2.2
|
26
33
|
script: "bundle exec rake $RAKE_TASK"
|
data/CHANGELOG.md
ADDED
data/CONTRIBUTING.md
CHANGED
@@ -25,9 +25,9 @@ issue tracking software.
|
|
25
25
|
|
26
26
|
### `PRERELEASE`
|
27
27
|
|
28
|
-
1. Update `PRERELEASE` to match the `SUMMARY` in the branch name. If you branched from `master`, and [version.rb](lib/metasploit/version/version.rb) does not have `PRERELEASE` defined, then adding the following lines after `PATCH`:
|
28
|
+
1. Update `PRERELEASE` to match the `SUMMARY` in the branch name. If you branched from `master`, and [version.rb](lib/metasploit/version/version.rb) does not have `PRERELEASE` defined, then adding the following lines after `PATCH`:
|
29
29
|
```
|
30
|
-
# The prerelease version, scoped to the {PATCH} version number.
|
30
|
+
# The prerelease version, scoped to the {MAJOR}, {MINOR}, and {PATCH} version number.
|
31
31
|
PRERELEASE = '<SUMMARY>'
|
32
32
|
```
|
33
33
|
2. `rake spec`
|
@@ -36,7 +36,7 @@ PRERELEASE = '<SUMMARY>'
|
|
36
36
|
|
37
37
|
### Your changes
|
38
38
|
|
39
|
-
Make your changes or however many commits you like,
|
39
|
+
Make your changes or however many commits you like, committing each with `git commit`.
|
40
40
|
|
41
41
|
### Pre-Pull Request Testing
|
42
42
|
|
@@ -45,12 +45,12 @@ Make your changes or however many commits you like, commiting each with `git com
|
|
45
45
|
|
46
46
|
### Push
|
47
47
|
|
48
|
-
Push your branch to your fork on gitub: `git push
|
48
|
+
Push your branch to your fork on gitub: `git push TYPE/ISSUE/SUMMARY`
|
49
49
|
|
50
50
|
### Pull Request
|
51
51
|
|
52
52
|
* [Create new Pull Request](https://github.com/rapid7/metasploit-version/compare/)
|
53
|
-
* Add a Verification Steps comment
|
53
|
+
* Add a Verification Steps to the description comment
|
54
54
|
|
55
55
|
```
|
56
56
|
# Verification Steps
|
@@ -61,11 +61,12 @@ Push your branch to your fork on gitub: `git push push TYPE/ISSUE/SUMMARY`
|
|
61
61
|
- [ ] `rake spec`
|
62
62
|
- [ ] VERIFY no failures
|
63
63
|
```
|
64
|
+
|
64
65
|
You should also include at least one scenario to manually check the changes outside of specs.
|
65
66
|
|
66
67
|
* Add a Post-merge Steps comment
|
67
68
|
|
68
|
-
The 'Post-merge Steps' are a reminder to the reviewer of the Pull Request of how to update the [`PRERELEASE`](lib/metasploit/version/version.rb) so that [version_spec.rb](spec/lib/metasploit/version/
|
69
|
+
The 'Post-merge Steps' are a reminder to the reviewer of the Pull Request of how to update the [`PRERELEASE`](lib/metasploit/version/version.rb) so that [version_spec.rb](spec/lib/metasploit/version/version.rb_spec.rb) passes on the target branch after the merge.
|
69
70
|
|
70
71
|
DESTINATION is the name of the destination branch into which the merge is being made. SOURCE_SUMMARY is the SUMMARY from TYPE/ISSUE/SUMMARY branch name for the SOURCE branch that is being made.
|
71
72
|
|
@@ -105,7 +106,7 @@ Perform these steps prior to pushing to DESTINATION or the build will be broke o
|
|
105
106
|
- [ ] Change `PRERELEASE` from `SOURCE_SUMMARY` to `DESTINATION_SUMMARY` to match the branch (DESTINATION) summary (DESTINATION_SUMMARY)
|
106
107
|
|
107
108
|
## Gem build
|
108
|
-
- [ ] gem build
|
109
|
+
- [ ] gem build metasploit-version.gemspec
|
109
110
|
- [ ] VERIFY the prerelease suffix has change on the gem.
|
110
111
|
|
111
112
|
## RSpec
|
@@ -117,40 +118,5 @@ Perform these steps prior to pushing to DESTINATION or the build will be broke o
|
|
117
118
|
- [ ] `git push origin DESTINATION`
|
118
119
|
```
|
119
120
|
|
120
|
-
|
121
|
-
|
122
|
-
The 'Release Steps' are a reminder to the reviewer of the Pull Request of how to release the gem.
|
123
|
-
|
124
|
-
```
|
125
|
-
# Release
|
126
|
-
|
127
|
-
Complete these steps on DESTINATION
|
128
|
-
|
129
|
-
## `VERSION`
|
130
|
-
|
131
|
-
### Compatible changes
|
132
|
-
|
133
|
-
If your change are compatible with the previous branch's API, then increment [`PATCH`](lib/metasploit/version/version.rb).
|
134
|
-
|
135
|
-
### Incompatible changes
|
136
|
-
|
137
|
-
If your changes are incompatible with the previous branch's API, then increment [`MINOR`](lib/metasploit/version/version.rb) and reset [`PATCH`](lib/metasploit/version/version.rb) to `0`.
|
138
|
-
|
139
|
-
- [ ] Following the rules for [semantic versioning 2.0](http://semver.org/spec/v2.0.0.html), update [`MINOR`](lib/metasploit/version/version.rb) and [`PATCH`](lib/metasploit/version/version.rb) and commit the changes.
|
140
|
-
|
141
|
-
## JRuby
|
142
|
-
- [ ] `rvm use jruby@metasploit-version`
|
143
|
-
- [ ] `rm Gemfile.lock`
|
144
|
-
- [ ] `bundle install`
|
145
|
-
- [ ] `rake release`
|
146
|
-
|
147
|
-
## MRI Ruby
|
148
|
-
- [ ] `rvm use ruby-2.1@metasploit-version`
|
149
|
-
- [ ] `rm Gemfile.lock`
|
150
|
-
- [ ] `bundle install`
|
151
|
-
- [ ] `rake release`
|
152
|
-
```
|
153
|
-
|
154
|
-
### Downstream dependencies
|
155
|
-
|
156
|
-
There are currently no known downstream dependencies
|
121
|
+
To update the [CHANGELOG.md](CHANGELOG.md) with the merged changes or release the merged code see
|
122
|
+
[RELEASING.md](RELEASING.md)
|
data/Gemfile
CHANGED
@@ -5,13 +5,17 @@ gemspec
|
|
5
5
|
|
6
6
|
group :test do
|
7
7
|
# Test the shared example
|
8
|
-
gem 'aruba'
|
9
|
-
|
10
|
-
|
11
|
-
|
12
|
-
|
13
|
-
#
|
8
|
+
gem 'aruba', github: 'rapid7/aruba', tag: 'v0.6.3.pre.metasploit.pre.yard.pre.port'
|
9
|
+
|
10
|
+
platform :mri do
|
11
|
+
# Upload spec coverage to codeclimate.com
|
12
|
+
gem 'codeclimate-test-reporter', require: false
|
13
|
+
# Upload spec coverage to coveralls.io
|
14
|
+
gem 'coveralls', require: false
|
15
|
+
# code coverage for specs
|
16
|
+
gem 'simplecov', require: false
|
17
|
+
end
|
18
|
+
|
19
|
+
# Test the shared example
|
14
20
|
gem 'cucumber'
|
15
|
-
# code coverage for specs
|
16
|
-
gem 'simplecov', require: false
|
17
21
|
end
|
data/RELEASING.md
ADDED
@@ -0,0 +1,86 @@
|
|
1
|
+
# Releasing
|
2
|
+
|
3
|
+
These steps can be added to the Pull Request description's task list to remind the reviewer of how to release the
|
4
|
+
gem.
|
5
|
+
|
6
|
+
```
|
7
|
+
# Release
|
8
|
+
|
9
|
+
Complete these steps on DESTINATION
|
10
|
+
|
11
|
+
## [CHANGELOG.md](CHANGELOG.md)
|
12
|
+
|
13
|
+
### Terminology
|
14
|
+
|
15
|
+
* "Enhancements" are widdening the API, such as by adding new classes or methods.
|
16
|
+
* "Bug Fixes" are fixes to the implementation that do not affect the public API. If the public API is affected then
|
17
|
+
the change should be listed as both a "Bug Fix" and either an "Enhancement" or "Incompatible Change" depending on how
|
18
|
+
the bug was fixed.
|
19
|
+
* "Deprecations" are changes to the implementation that cause deprecation warnings to be issued for APIs which will be
|
20
|
+
removed in a future major release. "Deprecations" are usually accompanied by an Enhancement that creates a new API
|
21
|
+
that is meant to be used in favor of the deprecated API.
|
22
|
+
* "Incompatbile Changes" are the removal of classes or methods or new required arguments or setup that shrink the API.
|
23
|
+
It is best practice to make a "Deprecation" for the API prior to its removal.
|
24
|
+
|
25
|
+
### Task List
|
26
|
+
|
27
|
+
- [ ] Generate the list of changes since the last release: `git log v<LAST_MAJOR>.<LAST_MINOR>.<LAST_PATCH>..HEAD`
|
28
|
+
- [ ] For each commit in the release, find the corresponding PR by search for the commit on Github.
|
29
|
+
- [ ] For each PR, determine whether it is an Enhancement, Bug Fix, Deprecation, and/or Incompatible Change. A PR can
|
30
|
+
be in more than one category, in which case it should be listed in each category it belongs, but with a category
|
31
|
+
specific description of the change.
|
32
|
+
- [ ] Add an item to each category's list in the following format: `[#<PR>](https://github.com/rapid7/metasploit-version/pull/<PR>) <consumer summary> - [@<github_user>](https://github.com/<github_user>)`
|
33
|
+
`consumer_summary` should be a summary of the Enhancement, Bug Fix, Deprecation, or Incompatible Change from a
|
34
|
+
downstream consumer's of the library's perspective. `github_user` should be Github handle of the author of the
|
35
|
+
PR.
|
36
|
+
- [ ] If you added any Deprecations or Incompatible Changes, then adding upgrading information to
|
37
|
+
[UPGRADING.md](UPGRADING.md)
|
38
|
+
|
39
|
+
## `VERSION`
|
40
|
+
|
41
|
+
The entries in the [CHANGELOG.md](CHANGELOG.md) can be used to help determine how the `VERSION` should be bumped.
|
42
|
+
|
43
|
+
### Compatible changes
|
44
|
+
|
45
|
+
If the [CHANGELOG.md](CHANGELOG.md) contains only Enhancements, Bug Fixes, and/or Deprecations for the Next Release then
|
46
|
+
increment [`PATCH`](lib/metasploit/version/version.rb).
|
47
|
+
|
48
|
+
### Incompatible changes
|
49
|
+
|
50
|
+
If the [CHANGELOG.md](CHANGELOG.md) contains any Incompatible Changes for the Next Release, then you can either (1)
|
51
|
+
decide to remain pre-1.0.0 or (2) advance to 1.0.0.
|
52
|
+
|
53
|
+
1. To remain pre-1..0.0, then increment [`MINOR`](lib/metasploit/version/version.rb) and reset [`PATCH`](lib/metasploit/version/version.rb) to `0`.
|
54
|
+
2. To advance to 1.0.0, increment [`MAJOR`](lib/metasploit/version/version.rb) and reset [`MINOR`](lib/metasploit/version/version.rb and [`PATCH`](lib/metasploit/version/version.rb) to `0`.
|
55
|
+
|
56
|
+
## Setup [CHANGELOG.md](CHANGELOG.md) for next release
|
57
|
+
|
58
|
+
- [ ] Change `Next Release` section name at the top of [CHANGELOG.md](CHANGELOG.md) to match the current `VERSION`.
|
59
|
+
- [ ] Add a new `Next Release` section above the `VERSION`'s section you just renamed:
|
60
|
+
<pre>
|
61
|
+
# Next Release
|
62
|
+
|
63
|
+
* Enhancements
|
64
|
+
* Bug Fixes
|
65
|
+
* Deprecations
|
66
|
+
* Incompatible Changes
|
67
|
+
</pre>
|
68
|
+
|
69
|
+
## Release to rubygems.org
|
70
|
+
|
71
|
+
## jruby
|
72
|
+
- [ ] `rvm use jruby@metasploit-version`
|
73
|
+
- [ ] `rm Gemfile.lock`
|
74
|
+
- [ ] `bundle install`
|
75
|
+
- [ ] `rake release`
|
76
|
+
|
77
|
+
## ruby-2.1
|
78
|
+
- [ ] `rvm use ruby-2.1@metasploit-version`
|
79
|
+
- [ ] `rm Gemfile.lock`
|
80
|
+
- [ ] `bundle install`
|
81
|
+
- [ ] `rake release`
|
82
|
+
```
|
83
|
+
|
84
|
+
### Downstream dependencies
|
85
|
+
|
86
|
+
There are currently no known downstream dependencies
|
data/Rakefile
CHANGED
@@ -1,12 +1,13 @@
|
|
1
1
|
require 'bundler/gem_tasks'
|
2
|
+
require 'bundler/setup'
|
3
|
+
|
4
|
+
require 'cucumber'
|
5
|
+
require 'cucumber/rake/task'
|
2
6
|
require 'rspec/core/rake_task'
|
3
7
|
|
4
8
|
RSpec::Core::RakeTask.new(:spec)
|
5
9
|
|
6
|
-
task :
|
7
|
-
|
8
|
-
require 'cucumber'
|
9
|
-
require 'cucumber/rake/task'
|
10
|
+
task default: :spec
|
10
11
|
|
11
12
|
Cucumber::Rake::Task.new do |t|
|
12
13
|
t.cucumber_opts = 'features --format pretty'
|
data/UPGRADING.md
ADDED
@@ -0,0 +1 @@
|
|
1
|
+
No Deprecations or Incompatible Changes have been introduced at this time
|
@@ -0,0 +1,18 @@
|
|
1
|
+
# Next Release
|
2
|
+
|
3
|
+
* Enhancements
|
4
|
+
* Bug Fixes
|
5
|
+
* Deprecations
|
6
|
+
* Incompatible Changes
|
7
|
+
|
8
|
+
# 0.1.2
|
9
|
+
|
10
|
+
* Enhancements
|
11
|
+
* [#1](https://github.com/rapid7/metasploit-version/pull/1) "Metasploit::Version GEM_VERSION constant",
|
12
|
+
"Metasploit::Version VERSION constant", and "Metasploit::Version Version Module" shared examples for checking
|
13
|
+
semantic versioning in projects. - [@limhoff-r7](https://github.com/limhoff-r7)
|
14
|
+
* [#2](https://github.com/rapid7/metasploit-version/pull/2) Use of metasploit-yard to ensure full documentation
|
15
|
+
coverage on travis-ci. - [@limhoff-r7](https://github.com/limhoff-r7)
|
16
|
+
* Bug Fixes
|
17
|
+
* Deprecations
|
18
|
+
* Incompatible Changes
|
@@ -0,0 +1,122 @@
|
|
1
|
+
# Contributing
|
2
|
+
|
3
|
+
## Forking
|
4
|
+
|
5
|
+
[Fork this repository](<%= github_url %>/fork)
|
6
|
+
|
7
|
+
## Branching
|
8
|
+
|
9
|
+
Branch names follow the format `TYPE/ISSUE/SUMMARY`. You can create it with `git checkout -b TYPE/ISSUE/SUMMARY`.
|
10
|
+
|
11
|
+
### `TYPE`
|
12
|
+
|
13
|
+
`TYPE` can be `bug`, `chore`, or `feature`.
|
14
|
+
|
15
|
+
### `ISSUE`
|
16
|
+
|
17
|
+
`ISSUE` is either a [Github issue](<%= github_url %>/issues) or an issue from some other
|
18
|
+
issue tracking software.
|
19
|
+
|
20
|
+
### `SUMMARY`
|
21
|
+
|
22
|
+
`SUMMARY` is is short summary of the purpose of the branch composed of lower case words separated by '-' so that it is a valid `PRERELEASE` for the Gem version.
|
23
|
+
|
24
|
+
## Changes
|
25
|
+
|
26
|
+
### `PRERELEASE`
|
27
|
+
|
28
|
+
1. Update `PRERELEASE` to match the `SUMMARY` in the branch name. If you branched from `master`, and [version.rb](<%= version_path %>) does not have `PRERELEASE` defined, then adding the following lines after `PATCH`:
|
29
|
+
```
|
30
|
+
# The prerelease version, scoped to the {MAJOR}, {MINOR}, and {PATCH} version number.
|
31
|
+
PRERELEASE = '<SUMMARY>'
|
32
|
+
```
|
33
|
+
2. `rake spec`
|
34
|
+
3. Verify the specs pass, which indicates that `PRERELEASE` was updated correctly.
|
35
|
+
4. Commit the change `git commit -a`
|
36
|
+
|
37
|
+
### Your changes
|
38
|
+
|
39
|
+
Make your changes or however many commits you like, committing each with `git commit`.
|
40
|
+
|
41
|
+
### Pre-Pull Request Testing
|
42
|
+
|
43
|
+
1. Run specs one last time before opening the Pull Request: `rake spec`
|
44
|
+
2. Verify there was no failures.
|
45
|
+
|
46
|
+
### Push
|
47
|
+
|
48
|
+
Push your branch to your fork on gitub: `git push TYPE/ISSUE/SUMMARY`
|
49
|
+
|
50
|
+
### Pull Request
|
51
|
+
|
52
|
+
* [Create new Pull Request](<%= github_url %>/compare/)
|
53
|
+
* Add a Verification Steps to the description comment
|
54
|
+
|
55
|
+
```
|
56
|
+
# Verification Steps
|
57
|
+
|
58
|
+
- [ ] `bundle install`
|
59
|
+
|
60
|
+
## `rake spec`
|
61
|
+
- [ ] `rake spec`
|
62
|
+
- [ ] VERIFY no failures
|
63
|
+
```
|
64
|
+
|
65
|
+
You should also include at least one scenario to manually check the changes outside of specs.
|
66
|
+
|
67
|
+
* Add a Post-merge Steps comment
|
68
|
+
|
69
|
+
The 'Post-merge Steps' are a reminder to the reviewer of the Pull Request of how to update the [`PRERELEASE`](<%= version_path %>) so that [version_spec.rb](spec/<%= version_path %>_spec.rb) passes on the target branch after the merge.
|
70
|
+
|
71
|
+
DESTINATION is the name of the destination branch into which the merge is being made. SOURCE_SUMMARY is the SUMMARY from TYPE/ISSUE/SUMMARY branch name for the SOURCE branch that is being made.
|
72
|
+
|
73
|
+
When merging to `master`:
|
74
|
+
|
75
|
+
```
|
76
|
+
# Post-merge Steps
|
77
|
+
|
78
|
+
Perform these steps prior to pushing to master or the build will be broke on master.
|
79
|
+
|
80
|
+
## Version
|
81
|
+
- [ ] Edit `<%= version_path %>`
|
82
|
+
- [ ] Remove `PRERELEASE` and its comment as `PRERELEASE` is not defined on master.
|
83
|
+
|
84
|
+
## Gem build
|
85
|
+
- [ ] gem build *.gemspec
|
86
|
+
- [ ] VERIFY the gem has no '.pre' version suffix.
|
87
|
+
|
88
|
+
## RSpec
|
89
|
+
- [ ] `rake spec`
|
90
|
+
- [ ] VERIFY version examples pass without failures
|
91
|
+
|
92
|
+
## Commit & Push
|
93
|
+
- [ ] `git commit -a`
|
94
|
+
- [ ] `git push origin master`
|
95
|
+
```
|
96
|
+
|
97
|
+
When merging to DESTINATION other than `master`:
|
98
|
+
|
99
|
+
```
|
100
|
+
# Post-merge Steps
|
101
|
+
|
102
|
+
Perform these steps prior to pushing to DESTINATION or the build will be broke on DESTINATION.
|
103
|
+
|
104
|
+
## Version
|
105
|
+
- [ ] Edit `<%= version_path %>`
|
106
|
+
- [ ] Change `PRERELEASE` from `SOURCE_SUMMARY` to `DESTINATION_SUMMARY` to match the branch (DESTINATION) summary (DESTINATION_SUMMARY)
|
107
|
+
|
108
|
+
## Gem build
|
109
|
+
- [ ] gem build <%= name %>.gemspec
|
110
|
+
- [ ] VERIFY the prerelease suffix has change on the gem.
|
111
|
+
|
112
|
+
## RSpec
|
113
|
+
- [ ] `rake spec`
|
114
|
+
- [ ] VERIFY version examples pass without failures
|
115
|
+
|
116
|
+
## Commit & Push
|
117
|
+
- [ ] `git commit -a`
|
118
|
+
- [ ] `git push origin DESTINATION`
|
119
|
+
```
|
120
|
+
|
121
|
+
To update the [CHANGELOG.md](CHANGELOG.md) with the merged changes or release the merged code see
|
122
|
+
[RELEASING.md](RELEASING.md)
|
@@ -0,0 +1,99 @@
|
|
1
|
+
# Releasing
|
2
|
+
|
3
|
+
These steps can be added to the Pull Request description's task list to remind the reviewer of how to release the
|
4
|
+
gem.
|
5
|
+
|
6
|
+
```
|
7
|
+
# Release
|
8
|
+
|
9
|
+
Complete these steps on DESTINATION
|
10
|
+
|
11
|
+
## [CHANGELOG.md](CHANGELOG.md)
|
12
|
+
|
13
|
+
### Terminology
|
14
|
+
|
15
|
+
* "Enhancements" are widdening the API, such as by adding new classes or methods.
|
16
|
+
* "Bug Fixes" are fixes to the implementation that do not affect the public API. If the public API is affected then
|
17
|
+
the change should be listed as both a "Bug Fix" and either an "Enhancement" or "Incompatible Change" depending on how
|
18
|
+
the bug was fixed.
|
19
|
+
* "Deprecations" are changes to the implementation that cause deprecation warnings to be issued for APIs which will be
|
20
|
+
removed in a future major release. "Deprecations" are usually accompanied by an Enhancement that creates a new API
|
21
|
+
that is meant to be used in favor of the deprecated API.
|
22
|
+
* "Incompatbile Changes" are the removal of classes or methods or new required arguments or setup that shrink the API.
|
23
|
+
It is best practice to make a "Deprecation" for the API prior to its removal.
|
24
|
+
|
25
|
+
### Task List
|
26
|
+
|
27
|
+
- [ ] Generate the list of changes since the last release: `git log v<LAST_MAJOR>.<LAST_MINOR>.<LAST_PATCH>..HEAD`
|
28
|
+
- [ ] For each commit in the release, find the corresponding PR by search for the commit on Github.
|
29
|
+
- [ ] For each PR, determine whether it is an Enhancement, Bug Fix, Deprecation, and/or Incompatible Change. A PR can
|
30
|
+
be in more than one category, in which case it should be listed in each category it belongs, but with a category
|
31
|
+
specific description of the change.
|
32
|
+
- [ ] Add an item to each category's list in the following format: `[#<PR>](<%= github_url %>/pull/<PR>) <consumer summary> - [@<github_user>](https://github.com/<github_user>)`
|
33
|
+
`consumer_summary` should be a summary of the Enhancement, Bug Fix, Deprecation, or Incompatible Change from a
|
34
|
+
downstream consumer's of the library's perspective. `github_user` should be Github handle of the author of the
|
35
|
+
PR.
|
36
|
+
- [ ] If you added any Deprecations or Incompatible Changes, then adding upgrading information to
|
37
|
+
[UPGRADING.md](UPGRADING.md)
|
38
|
+
|
39
|
+
## `VERSION`
|
40
|
+
|
41
|
+
The entries in the [CHANGELOG.md](CHANGELOG.md) can be used to help determine how the `VERSION` should be bumped.
|
42
|
+
|
43
|
+
<%- if options[:major] < 1 -%>
|
44
|
+
### Compatible changes
|
45
|
+
|
46
|
+
If the [CHANGELOG.md](CHANGELOG.md) contains only Enhancements, Bug Fixes, and/or Deprecations for the Next Release then
|
47
|
+
increment [`PATCH`](<%= version_path %>).
|
48
|
+
|
49
|
+
### Incompatible changes
|
50
|
+
|
51
|
+
If the [CHANGELOG.md](CHANGELOG.md) contains any Incompatible Changes for the Next Release, then you can either (1)
|
52
|
+
decide to remain pre-1.0.0 or (2) advance to 1.0.0.
|
53
|
+
|
54
|
+
1. To remain pre-1..0.0, then increment [`MINOR`](<%= version_path %>) and reset [`PATCH`](<%= version_path %>) to `0`.
|
55
|
+
2. To advance to 1.0.0, increment [`MAJOR`](<%= version_path %>) and reset [`MINOR`](<%= version_path %> and [`PATCH`](<%= version_path %>) to `0`.
|
56
|
+
<%- else -%>
|
57
|
+
### Bug fixes
|
58
|
+
|
59
|
+
If the [CHANGELOG.md](CHANGELOG.md) contains only Bug Fixes for the Next Release, then increment
|
60
|
+
[`PATCH`](<%= version_path %>).
|
61
|
+
|
62
|
+
### Compatible API changes
|
63
|
+
|
64
|
+
If the [CHANGELOG.md](CHANGELOG.md) contains any Enhancements or Deprecations, then increment
|
65
|
+
[`MINOR`](<%= version_path %>) and reset [`PATCH`](<%= version_path %>) to `0`.
|
66
|
+
|
67
|
+
### Incompatible API changes
|
68
|
+
|
69
|
+
If the [CHANGELOG.md](CHANGELOG.md) contains any Incompatible Change, then increment [`MAJOR`](<%= version_path %>) and
|
70
|
+
reset [`MINOR`](<%= version_path %> and [`PATCH`](<%= version_path %>) to `0`.
|
71
|
+
<%- end -%>
|
72
|
+
|
73
|
+
## Setup [CHANGELOG.md](CHANGELOG.md) for next release
|
74
|
+
|
75
|
+
- [ ] Change `Next Release` section name at the top of [CHANGELOG.md](CHANGELOG.md) to match the current `VERSION`.
|
76
|
+
- [ ] Add a new `Next Release` section above the `VERSION`'s section you just renamed:
|
77
|
+
<pre>
|
78
|
+
# Next Release
|
79
|
+
|
80
|
+
* Enhancements
|
81
|
+
* Bug Fixes
|
82
|
+
* Deprecations
|
83
|
+
* Incompatible Changes
|
84
|
+
</pre>
|
85
|
+
|
86
|
+
## Release to rubygems.org
|
87
|
+
<%- options[:ruby_versions].each do |ruby_version| -%>
|
88
|
+
|
89
|
+
## <%= ruby_version %>
|
90
|
+
- [ ] `rvm use <%= ruby_version %>@<%= name %>`
|
91
|
+
- [ ] `rm Gemfile.lock`
|
92
|
+
- [ ] `bundle install`
|
93
|
+
- [ ] `rake release`
|
94
|
+
<%- end -%>
|
95
|
+
```
|
96
|
+
|
97
|
+
### Downstream dependencies
|
98
|
+
|
99
|
+
There are currently no known downstream dependencies
|