Proposal: use versions for other Ruby gems too.

[HonkingGoose]

I noticed that https://github.com/progit/progit2/blob/master/Gemfile only has versions listed for:

• gem 'asciidoctor', '1.5.6.2'
• gem 'asciidoctor-epub3', '~> 1.5.0.alpha.9'
• gem 'asciidoctor-pdf', '~> 1.5.0.beta.8'

But no versions are listed for:

• gem 'rake'
• gem 'json'
• gem 'awesome_print'
• gem 'coderay'
• gem 'pygments.rb'
• gem 'thread_safe'
• gem 'epubcheck'
• gem 'kindlegen'

It might be worth it to give known working versions to the other dependencies. That way Dependabot can help keep those up to date too.

Doing this will also ensure that contributors/maintainers are on the same versions of everything, this might reduce instances of "Well it works on my computer, but not on Ben's.".

---

Unable to install a working set of gems:

I'm going to bump this issue as I tried to install Asciidoctor on my Windows 10 system and couldn't get a working set of dependencies installed with the bundle install command.

The problem is that the gems that are not given a version range will download the latest version of their gems, but those gems are not automatically compatible with the outdated version of Asciidoctor that we use.

From memory, I think the issue was with the 'coderay' gem.

I would really like to get a known working version range for all dependencies, instead of relying on the latest versions of some dependencies being compatible with the outdated version of Asciidoctor.

Options to fix this:

• My preferred method would be to implement PR Switch to asciidoctor 2.0.10 #1373, so that we're back on a supported version of Asciidoctor again, and afterwards use a proper version range.
• Alternatively we use the version range that is currently in use on the maintainers workstation.

---

History of the change:

I also noticed the project used to have the gems locked to a specific version but that caused issues for aollier in getting a working tool-chain on his Fedora 25 system. #684

The argument given in favor of removal:

It is unnecessary to track Gemfile.lock because it is platform dependent and it causes problems to build the book.

And a argument in favor of keeping the gem lock file:

Well, the Gemfile.lock is supposed to insure a known-good combination of packages. But, right now, this leads to compilation errors indeed.