metasploit-version 0.1.2 → 0.1.3

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA1:
-  metadata.gz: 81bcd1c0b7d61d6e30a6fad4b1ac333dbb7581ab
-  data.tar.gz: 447c56d81b51a5437146f56d65eeeebc85122dff
+  metadata.gz: 0639f55c4c44ec7c827d95de7869fcc145c6824a
+  data.tar.gz: fd49300f81ff75599699c597e553716f6cbfdde4
 SHA512:
-  metadata.gz: 5dd755bdc48758ee7729493f496e9c216c845208b5fd84e02abab70fe6a02472e1b21aad3e50e0eb7d701f823191bf7e97f0adda2a1401d4e350d6d14aa50715
-  data.tar.gz: a12d1c52252e8c7f4daddd712a6c99cc1d380977d3f5a58a4783f99122271fec2e91fd2f73c699644c7a3aa1ae614bf9e27f9169ade1932634c55f971d289e77
+  metadata.gz: 43a72b0c93f2b56fff17b2392a0a0fc99496fb51df5683377c0e9b24b3548ee63bd44dab039d4b46d82d9eb91f65a580dffdfd642bf17025ea354a0626ffe001
+  data.tar.gz: 0826173a4969daac2f43b89b7f77f0b3384dddbb9337218d148f5a24b990954dc0927a60722fd9649a67048a3fe792a972e447311d2ad969bd25adc0bd121f92

data/.rspec

@@ -0,0 +1,2 @@
+--color
+--require spec_helper

data/.travis.yml

@@ -9,18 +9,25 @@ matrix:
   allow_failures:
     - rvm: ruby-head
   fast_finish: true
-  # documentation coverage is not influenced by ruby version, but the dependencies differ for MRI and JRuby, so
-  # rake yard for both.
   include:
+    # documentation coverage is not influenced by ruby version, but the dependencies differ for MRI and JRuby, so
+    # rake yard for both.
     - rvm: 2.1
       env: RAKE_TASK=yard
     - rvm: jruby
       env: RAKE_TASK=yard
+    # Advised to turn off JIT with RBXOPT-Xint by @rubinius on twiiter
+    # @see https://twitter.com/rubinius/status/518563456363274240
+    # @see https://twitter.com/rubinius/status/518563552953917440
+    - rvm: rbx-2.2
+      env: RAKE_TASK=cucumber RBXOPT=-Xint
+    - rvm: rbx-2.2
+      env: RAKE_TASK=spec RBXOPT=-Xint
+
 rvm:
 - 1.9.3
 - 2.0
 - 2.1
 - ruby-head
 - jruby
-- rbx-2.2
 script: "bundle exec rake $RAKE_TASK"

data/CHANGELOG.md

@@ -0,0 +1,6 @@
+# Next Release
+
+* Enhancements
+* Bug Fixes
+* Deprecations
+* Incompatible Changes

data/CONTRIBUTING.md

@@ -25,9 +25,9 @@ issue tracking software.
 
 ### `PRERELEASE`
 
-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`: 
+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`:
 ```
-# The prerelease version, scoped to the {PATCH} version number.
+# The prerelease version, scoped to the {MAJOR}, {MINOR}, and {PATCH} version number.
 PRERELEASE = '<SUMMARY>'
 ```
 2. `rake spec`
@@ -36,7 +36,7 @@ PRERELEASE = '<SUMMARY>'
 
 ### Your changes
 
-Make your changes or however many commits you like, commiting each with `git commit`.
+Make your changes or however many commits you like, committing each with `git commit`.
 
 ### Pre-Pull Request Testing
 
@@ -45,12 +45,12 @@ Make your changes or however many commits you like, commiting each with `git com
 
 ### Push
 
-Push your branch to your fork on gitub: `git push push TYPE/ISSUE/SUMMARY`
+Push your branch to your fork on gitub: `git push TYPE/ISSUE/SUMMARY`
 
 ### Pull Request
 
 * [Create new Pull Request](https://github.com/rapid7/metasploit-version/compare/)
-* Add a Verification Steps comment
+* Add a Verification Steps to the description comment
 
 ```
 # Verification Steps
@@ -61,11 +61,12 @@ Push your branch to your fork on gitub: `git push push TYPE/ISSUE/SUMMARY`
 - [ ] `rake spec`
 - [ ] VERIFY no failures
 ```
+
 You should also include at least one scenario to manually check the changes outside of specs.
 
 * Add a Post-merge Steps comment
 
-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_spec.rb) passes on the target branch after the merge.
+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.
 
 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.
 
@@ -105,7 +106,7 @@ Perform these steps prior to pushing to DESTINATION or the build will be broke o
 - [ ] Change `PRERELEASE` from `SOURCE_SUMMARY` to `DESTINATION_SUMMARY` to match the branch (DESTINATION) summary (DESTINATION_SUMMARY)
 
 ## Gem build
-- [ ] gem build *.gemspec
+- [ ] gem build metasploit-version.gemspec
 - [ ] VERIFY the prerelease suffix has change on the gem.
 
 ## RSpec
@@ -117,40 +118,5 @@ Perform these steps prior to pushing to DESTINATION or the build will be broke o
 - [ ] `git push origin DESTINATION`
 ```
 
-* Add a 'Release Steps' comment
-
-The 'Release Steps' are a reminder to the reviewer of the Pull Request of how to release the gem.
-
-```
-# Release
-
-Complete these steps on DESTINATION
-
-## `VERSION`
-
-### Compatible changes
-
-If your change are compatible with the previous branch's API, then increment [`PATCH`](lib/metasploit/version/version.rb).
-
-### Incompatible changes
-
-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`.
-
-- [ ] 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.
-
-## JRuby
-- [ ] `rvm use jruby@metasploit-version`
-- [ ] `rm Gemfile.lock`
-- [ ] `bundle install`
-- [ ] `rake release`
-
-## MRI Ruby
-- [ ] `rvm use ruby-2.1@metasploit-version`
-- [ ] `rm Gemfile.lock`
-- [ ] `bundle install`
-- [ ] `rake release`
-```
-
-### Downstream dependencies
-
-There are currently no known downstream dependencies
+To update the [CHANGELOG.md](CHANGELOG.md) with the merged changes or release the merged code see
+[RELEASING.md](RELEASING.md)

data/Gemfile

@@ -5,13 +5,17 @@ gemspec
 
 group :test do
   # Test the shared example
-  gem 'aruba'
-  # Upload spec coverage to codeclimate.com
-  gem 'codeclimate-test-reporter', require: false
-  # Upload spec coverage to coveralls.io
-  gem 'coveralls', require: false
-    # Test the shared example
+  gem 'aruba', github: 'rapid7/aruba', tag: 'v0.6.3.pre.metasploit.pre.yard.pre.port'
+
+  platform :mri do
+    # Upload spec coverage to codeclimate.com
+    gem 'codeclimate-test-reporter', require: false
+    # Upload spec coverage to coveralls.io
+    gem 'coveralls', require: false
+    # code coverage for specs
+    gem 'simplecov', require: false
+  end
+
+  # Test the shared example
   gem 'cucumber'
-  # code coverage for specs
-  gem 'simplecov', require: false
 end

data/RELEASING.md

@@ -0,0 +1,86 @@
+# Releasing
+
+These steps can be added to the Pull Request description's task list to remind the reviewer of how to release the
+gem.
+
+```
+# Release
+
+Complete these steps on DESTINATION
+
+## [CHANGELOG.md](CHANGELOG.md)
+
+### Terminology
+
+* "Enhancements" are widdening the API, such as by adding new classes or methods.
+* "Bug Fixes" are fixes to the implementation that do not affect the public API.  If the public API is affected then
+  the change should be listed as both a "Bug Fix" and either an "Enhancement" or "Incompatible Change" depending on how
+  the bug was fixed.
+* "Deprecations" are changes to the implementation that cause deprecation warnings to be issued for APIs which will be
+  removed in a future major release.  "Deprecations" are usually accompanied by an Enhancement that creates a new API
+  that is meant to be used in favor of the deprecated API.
+* "Incompatbile Changes" are the removal of classes or methods or new required arguments or setup that shrink the API.
+  It is best practice to make a "Deprecation" for the API prior to its removal.
+
+### Task List
+
+- [ ] Generate the list of changes since the last release: `git log v<LAST_MAJOR>.<LAST_MINOR>.<LAST_PATCH>..HEAD`
+- [ ] For each commit in the release, find the corresponding PR by search for the commit on Github.
+- [ ] For each PR, determine whether it is an Enhancement, Bug Fix, Deprecation, and/or Incompatible Change.  A PR can
+      be in more than one category, in which case it should be listed in each category it belongs, but with a category
+      specific description of the change.
+- [ ] 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>)`
+      `consumer_summary` should be a summary of the Enhancement, Bug Fix, Deprecation, or Incompatible Change from a
+      downstream consumer's of the library's perspective.  `github_user` should be Github handle of the author of the
+      PR.
+- [ ] If you added any Deprecations or Incompatible Changes, then adding upgrading information to
+      [UPGRADING.md](UPGRADING.md)
+
+## `VERSION`
+
+The entries in the [CHANGELOG.md](CHANGELOG.md) can be used to help determine how the `VERSION` should be bumped.
+
+### Compatible changes
+
+If the [CHANGELOG.md](CHANGELOG.md) contains only Enhancements, Bug Fixes, and/or Deprecations for the Next Release then
+increment [`PATCH`](lib/metasploit/version/version.rb).
+
+### Incompatible changes
+
+If the [CHANGELOG.md](CHANGELOG.md) contains any Incompatible Changes for the Next Release, then you can either (1)
+decide to remain pre-1.0.0 or (2) advance to 1.0.0.
+
+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`.
+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`.
+
+## Setup [CHANGELOG.md](CHANGELOG.md) for next release
+
+- [ ] Change `Next Release` section name at the top of [CHANGELOG.md](CHANGELOG.md) to match the current `VERSION`.
+- [ ] Add a new `Next Release` section above the `VERSION`'s section you just renamed:
+<pre>
+# Next Release
+
+* Enhancements
+* Bug Fixes
+* Deprecations
+* Incompatible Changes
+</pre>
+
+## Release to rubygems.org
+
+## jruby
+- [ ] `rvm use jruby@metasploit-version`
+- [ ] `rm Gemfile.lock`
+- [ ] `bundle install`
+- [ ] `rake release`
+
+## ruby-2.1
+- [ ] `rvm use ruby-2.1@metasploit-version`
+- [ ] `rm Gemfile.lock`
+- [ ] `bundle install`
+- [ ] `rake release`
+```
+
+### Downstream dependencies
+
+There are currently no known downstream dependencies

data/Rakefile

@@ -1,12 +1,13 @@
 require 'bundler/gem_tasks'
+require 'bundler/setup'
+
+require 'cucumber'
+require 'cucumber/rake/task'
 require 'rspec/core/rake_task'
 
 RSpec::Core::RakeTask.new(:spec)
 
-task :default => :spec
-
-require 'cucumber'
-require 'cucumber/rake/task'
+task default: :spec
 
 Cucumber::Rake::Task.new do |t|
   t.cucumber_opts = 'features --format pretty'

data/UPGRADING.md

@@ -0,0 +1 @@
+No Deprecations or Incompatible Changes have been introduced at this time

data/app/templates/.rspec.tt

@@ -0,0 +1,2 @@
+--color
+--require spec_helper

data/app/templates/CHANGELOG.md.tt

@@ -0,0 +1,18 @@
+# Next Release
+
+* Enhancements
+* Bug Fixes
+* Deprecations
+* Incompatible Changes
+
+# 0.1.2
+
+* Enhancements
+  * [#1](https://github.com/rapid7/metasploit-version/pull/1) "Metasploit::Version GEM_VERSION constant",
+    "Metasploit::Version VERSION constant", and "Metasploit::Version Version Module" shared examples for checking
+    semantic versioning in projects. - [@limhoff-r7](https://github.com/limhoff-r7)
+  * [#2](https://github.com/rapid7/metasploit-version/pull/2) Use of metasploit-yard to ensure full documentation
+    coverage on travis-ci. - [@limhoff-r7](https://github.com/limhoff-r7)
+* Bug Fixes
+* Deprecations
+* Incompatible Changes

data/app/templates/CONTRIBUTING.md.tt

@@ -0,0 +1,122 @@
+# Contributing
+
+## Forking
+
+[Fork this repository](<%= github_url %>/fork)
+
+## Branching
+
+Branch names follow the format `TYPE/ISSUE/SUMMARY`.  You can create it with `git checkout -b TYPE/ISSUE/SUMMARY`.
+
+### `TYPE`
+
+`TYPE` can be `bug`, `chore`, or `feature`.
+
+### `ISSUE`
+
+`ISSUE` is either a [Github issue](<%= github_url %>/issues) or an issue from some other
+issue tracking software.
+
+### `SUMMARY`
+
+`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.
+
+## Changes
+
+### `PRERELEASE`
+
+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`:
+```
+# The prerelease version, scoped to the {MAJOR}, {MINOR}, and {PATCH} version number.
+PRERELEASE = '<SUMMARY>'
+```
+2. `rake spec`
+3.  Verify the specs pass, which indicates that `PRERELEASE` was updated correctly.
+4. Commit the change `git commit -a`
+
+### Your changes
+
+Make your changes or however many commits you like, committing each with `git commit`.
+
+### Pre-Pull Request Testing
+
+1. Run specs one last time before opening the Pull Request: `rake spec`
+2. Verify there was no failures.
+
+### Push
+
+Push your branch to your fork on gitub: `git push TYPE/ISSUE/SUMMARY`
+
+### Pull Request
+
+* [Create new Pull Request](<%= github_url %>/compare/)
+* Add a Verification Steps to the description comment
+
+```
+# Verification Steps
+
+- [ ] `bundle install`
+
+## `rake spec`
+- [ ] `rake spec`
+- [ ] VERIFY no failures
+```
+
+You should also include at least one scenario to manually check the changes outside of specs.
+
+* Add a Post-merge Steps comment
+
+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.
+
+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.
+
+When merging to `master`:
+
+```
+# Post-merge Steps
+
+Perform these steps prior to pushing to master or the build will be broke on master.
+
+## Version
+- [ ] Edit `<%= version_path %>`
+- [ ] Remove `PRERELEASE` and its comment as `PRERELEASE` is not defined on master.
+
+## Gem build
+- [ ] gem build *.gemspec
+- [ ] VERIFY the gem has no '.pre' version suffix.
+
+## RSpec
+- [ ] `rake spec`
+- [ ] VERIFY version examples pass without failures
+
+## Commit & Push
+- [ ] `git commit -a`
+- [ ] `git push origin master`
+```
+
+When merging to DESTINATION other than `master`:
+
+```
+# Post-merge Steps
+
+Perform these steps prior to pushing to DESTINATION or the build will be broke on DESTINATION.
+
+## Version
+- [ ] Edit `<%= version_path %>`
+- [ ] Change `PRERELEASE` from `SOURCE_SUMMARY` to `DESTINATION_SUMMARY` to match the branch (DESTINATION) summary (DESTINATION_SUMMARY)
+
+## Gem build
+- [ ] gem build <%= name %>.gemspec
+- [ ] VERIFY the prerelease suffix has change on the gem.
+
+## RSpec
+- [ ] `rake spec`
+- [ ] VERIFY version examples pass without failures
+
+## Commit & Push
+- [ ] `git commit -a`
+- [ ] `git push origin DESTINATION`
+```
+
+To update the [CHANGELOG.md](CHANGELOG.md) with the merged changes or release the merged code see
+[RELEASING.md](RELEASING.md)

data/app/templates/RELEASING.md.tt

@@ -0,0 +1,99 @@
+# Releasing
+
+These steps can be added to the Pull Request description's task list to remind the reviewer of how to release the
+gem.
+
+```
+# Release
+
+Complete these steps on DESTINATION
+
+## [CHANGELOG.md](CHANGELOG.md)
+
+### Terminology
+
+* "Enhancements" are widdening the API, such as by adding new classes or methods.
+* "Bug Fixes" are fixes to the implementation that do not affect the public API.  If the public API is affected then
+  the change should be listed as both a "Bug Fix" and either an "Enhancement" or "Incompatible Change" depending on how
+  the bug was fixed.
+* "Deprecations" are changes to the implementation that cause deprecation warnings to be issued for APIs which will be
+  removed in a future major release.  "Deprecations" are usually accompanied by an Enhancement that creates a new API
+  that is meant to be used in favor of the deprecated API.
+* "Incompatbile Changes" are the removal of classes or methods or new required arguments or setup that shrink the API.
+  It is best practice to make a "Deprecation" for the API prior to its removal.
+
+### Task List
+
+- [ ] Generate the list of changes since the last release: `git log v<LAST_MAJOR>.<LAST_MINOR>.<LAST_PATCH>..HEAD`
+- [ ] For each commit in the release, find the corresponding PR by search for the commit on Github.
+- [ ] For each PR, determine whether it is an Enhancement, Bug Fix, Deprecation, and/or Incompatible Change.  A PR can
+      be in more than one category, in which case it should be listed in each category it belongs, but with a category
+      specific description of the change.
+- [ ] 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>)`
+      `consumer_summary` should be a summary of the Enhancement, Bug Fix, Deprecation, or Incompatible Change from a
+      downstream consumer's of the library's perspective.  `github_user` should be Github handle of the author of the
+      PR.
+- [ ] If you added any Deprecations or Incompatible Changes, then adding upgrading information to
+      [UPGRADING.md](UPGRADING.md)
+
+## `VERSION`
+
+The entries in the [CHANGELOG.md](CHANGELOG.md) can be used to help determine how the `VERSION` should be bumped.
+
+<%- if options[:major] < 1 -%>
+### Compatible changes
+
+If the [CHANGELOG.md](CHANGELOG.md) contains only Enhancements, Bug Fixes, and/or Deprecations for the Next Release then
+increment [`PATCH`](<%= version_path %>).
+
+### Incompatible changes
+
+If the [CHANGELOG.md](CHANGELOG.md) contains any Incompatible Changes for the Next Release, then you can either (1)
+decide to remain pre-1.0.0 or (2) advance to 1.0.0.
+
+1. To remain pre-1..0.0, then increment [`MINOR`](<%= version_path %>) and reset [`PATCH`](<%= version_path %>) to `0`.
+2. To advance to 1.0.0, increment [`MAJOR`](<%= version_path %>) and reset [`MINOR`](<%= version_path %> and [`PATCH`](<%= version_path %>) to `0`.
+<%- else -%>
+### Bug fixes
+
+If the [CHANGELOG.md](CHANGELOG.md) contains only Bug Fixes for the Next Release, then increment
+[`PATCH`](<%= version_path %>).
+
+### Compatible API changes
+
+If the [CHANGELOG.md](CHANGELOG.md) contains any Enhancements or Deprecations, then increment
+[`MINOR`](<%= version_path %>) and reset [`PATCH`](<%= version_path %>) to `0`.
+
+### Incompatible API changes
+
+If the [CHANGELOG.md](CHANGELOG.md) contains any Incompatible Change, then increment [`MAJOR`](<%= version_path %>) and
+reset [`MINOR`](<%= version_path %> and [`PATCH`](<%= version_path %>) to `0`.
+<%- end -%>
+
+## Setup [CHANGELOG.md](CHANGELOG.md) for next release
+
+- [ ] Change `Next Release` section name at the top of [CHANGELOG.md](CHANGELOG.md) to match the current `VERSION`.
+- [ ] Add a new `Next Release` section above the `VERSION`'s section you just renamed:
+<pre>
+# Next Release
+
+* Enhancements
+* Bug Fixes
+* Deprecations
+* Incompatible Changes
+</pre>
+
+## Release to rubygems.org
+<%- options[:ruby_versions].each do |ruby_version| -%>
+
+## <%= ruby_version %>
+- [ ] `rvm use <%= ruby_version %>@<%= name %>`
+- [ ] `rm Gemfile.lock`
+- [ ] `bundle install`
+- [ ] `rake release`
+<%- end -%>
+```
+
+### Downstream dependencies
+
+There are currently no known downstream dependencies