Release v2.0.0-pre, compatible with RuboCop v1.0

[bquorning]

As discussed in #1051 (comment), let’s make a 2.0 pre-release so our users can try out the new RuboCop v1.0.

I will hold off on pushing our documentation until we release the real v2.0. Does that sound ok?

---

Before submitting the PR make sure the following are checked:

• [-] Feature branch is up-to-date with master (if not - rebase it).
• Squashed related commits together.
• [-] Added tests.
• Updated documentation.
• Added an entry to the CHANGELOG.md if the new code introduces user-observable changes.
• The build (bundle exec rake) passes (be sure to run this locally, since it may produce updated documentation that you will need to commit).

[pirj]

Thanks!
Merge at will 👍

[pirj]

Oh. I never thought that no additional fixes will be needed.

ci/circleci: edge-rubocop Your tests passed on CircleCI!

🎉 🙌

[bquorning]

The additional fixes were added to #1019 yesterday :-)

[bquorning]

Wow, this feature of RubyGems caught me by surprise:

❯ ruby -e 'puts Gem::Version.create("2.0.0-pre")'
2.0.0.pre.pre

and

❯ bundle exec rake -T release
rake release[remote]  # Create tag v2.0.0.pre.pre and build and push rubocop-rspec-2.0.0.pre.pre.gem to rubygems.org

I’ve tracked down this behaviour to https://github.com/rubygems/rubygems/blob/3e71d3fcc22a354d5e698642497dabf77ce6c177/lib/rubygems/version.rb#L208-L222. I cannot see how @version = version.to_s.strip.gsub("-",".pre.") can work together with SemVer’s rules:

A pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following the patch version. (my emphasis) (source)

[bquorning]

It’s released as 2.0.0.pre

[pirj]

rubocop-rspec-2.0.0.pre.pre.gem
Ouch :D