Aggregate guides for 1.12-1.14 to 1.15

[tnir]

What was the end-user problem that led to this PR?

Guides for older Bundler versions (v1.12-v1.14) are still available via side nav bar and via search engines.

What was your diagnosis of the problem?

There was no (significant) change in these guides until #404 (which was for guides for v1.16).

What is your fix for the problem, implemented in this PR?

All guides (in en and pl) in v1.12 through v1.14 are now redirected to v1.15 guides in each language.

This PR:

• removes:
  • /v1.{12,13,14}/guides/{creating_gem,using_bundler_in_applications}.html files
• adds:
  • redirections from /v1.{12,13,14}/guides/{creating_gem,using_bundler_in_applications}.html to /v1.15/guides/{creating_gem,using_bundler_in_applications}.html
• replaces
  • links in Guide section in the side bar of /v1.{12,13,14}/whats_new.html with /v1.15/guides/{creating_gem,using_bundler_in_applications}.html

diff *.md between 1.12 and 1.15

$ diff -u source/localizable/v{1.12,1.15}/guides/creating_gem.en.html.md

--- source/localizable/v1.12/guides/creating_gem.en.html.md     2022-07-04 20:15:03.832843559 +0000
+++ source/localizable/v1.15/guides/creating_gem.en.html.md     2022-06-23 14:18:04.000000000 +0000
@@ -13,6 +13,13 @@
 our own gems? It's really easy to do this and Bundler provides a couple of things to help you 
 along this path.
 
+Related reading:
+
+* [Creating a gem with a C
+  extension](http://guides.rubygems.org/gems-with-extensions/)
+* [Common practices for developing
+  gems](http://guides.rubygems.org/patterns/)
+
 ## But first, why?
 
 Why should we create a gem? Can't we just throw in some code into our *other* library and use 
@@ -29,18 +36,21 @@
 we might not get the exact same output.  To check which version of bundler we currently have, 
 lets run the following command:
 
-    bundle -v
+    $ bundle -v
 
 We should see something close to `Bundler version 1.9.0`.  If necessary, we can update to the 
 newest version of Bundler by running `gem update bundler`.
 
 To begin to create a gem using Bundler, use the `bundle gem` command like this:
 
-    bundle gem foodie
+    $ bundle gem foodie
 
 We call our gem `foodie` because this gem is going to do a couple of things around food, such as 
 portraying them as either "Delicious!" or "Gross!". Stay tuned.
 
+For information on gem naming conventions, you can read the “[Name Your
+Gem](http://guides.rubygems.org/name-your-gem/)” guide on the RubyGems website.
+
 This command creates a [scaffold directory](https://github.com/radar/guides/tree/master/gem-scaffold/foodie)
 for our new gem and, if we have
 Git installed, initializes a Git repository in this directory so we can start committing right
@@ -290,11 +300,10 @@
 spec.add_development_dependency "aruba"
 ~~~
 
-Hot. Let's run `bundle install` to get these awesome tools set up.
+Cool. Let's run `bundle install` to get these awesome tools set up.
 
 Our CLI is going to have two methods, which correspond to the two methods which we have defined
-in `Foodie::Food`. We will now create a _features_ directory where we will make sweet, sweet love
-to Aruba to write tests for our CLI. In this directory we'll create a new file called
+in `Foodie::Food`. We will now create a _features_ directory where we will use Aruba to write tests for our CLI. In this directory we'll create a new file called
 _features/food.feature_ and fill it with this juicy code:
 
 ~~~ cucumber
@@ -325,7 +334,7 @@
 To run this feature, we use the `cucumber` command, but of course because it's available within
 the context of our bundle, we use `bundle exec cucumber` like this:
 
-    bundle exec cucumber features/
+    $ bundle exec cucumber features/
 
 See those yellow things? They're undefined steps:
 
@@ -370,7 +379,7 @@
 speaking of running, we should `chmod` this file to be an executable from our terminal:
 
 ~~~ bash
-chmod +x exe/foodie
+$ chmod +x exe/foodie
 ~~~
 
 Alright so we've got the executable file, now what? If we re-run our features we get *nothing*
@@ -681,8 +690,8 @@
 If we haven't already, we should commit all the files for our repository:
 
 ~~~ bash
-git add .
-git commit -m "The beginnings of the foodie gem"
+$ git add .
+$ git commit -m "The beginnings of the foodie gem"
 ~~~
 
 This is because the `foodie.gemspec` file uses `git ls-files` to detect which files should be 
@@ -714,15 +723,15 @@
 
 If we want to make this process a little easier we could install the "gem-release" gem with:
 
-    gem install gem-release
+    $ gem install gem-release
 
 This gem provides several methods for helping with gem development in general, but most helpful 
 is the `gem bump` command which will bump the gem version to the next patch level. This method 
 also takes options to do these things:
 
-    gem bump --version minor # bumps to the next minor version
-    gem bump --version major # bumps to the next major version
-    gem bump --version 1.1.1 # bumps to the specified version
+    $ gem bump --version minor # bumps to the next minor version
+    $ gem bump --version major # bumps to the next major version
+    $ gem bump --version 1.1.1 # bumps to the specified version
 
 For more information, check out the ["gem-release" GitHub repository 
 homepage](http://github.com/svenfuchs/gem-release).
@@ -739,4 +748,4 @@
 ***
 
 **Many thanks to author of this guide: [Ryan Bigg](https://github.com/radar). You can find more of his guides
-[here](https://github.com/radar/guides).**
\ No newline at end of file
+[here](https://github.com/radar/guides).**

$ diff -u source/localizable/v{1.12,1.15}/guides/using_bundler_in_applications.en.html.md

--- source/localizable/v1.12/guides/using_bundler_in_applications.en.html.md    2022-07-04 20:15:03.832843559 +0000
+++ source/localizable/v1.15/guides/using_bundler_in_applications.en.html.md    2022-06-23 14:18:04.000000000 +0000
@@ -23,20 +23,20 @@
 1. [Recommended Workflow](#recommended-workflow)
 1. [Troubleshooting](#troubleshooting)
     1. [Running `git bisect` in projects using Bundler](#running-git-bisect-in-projects-using-bundler)
-
+    
 ## Getting Started - Installing Bundler and **bundle init**
 
 **Some of the frameworks have builtin support for Bundler, e.g. when you run `rails new app` it
 will automatically init Bundler.**
 
 Firstly, we need to install Bundler.
-
-    gem install bundler
-
+ 
+    $ gem install bundler
+    
 This command will also update already installed bundler. You should get something similar as output:
 
 ~~~ bash
-[kruczjak:~/git] % gem install bundler
+$ gem install bundler
 Successfully installed bundler-1.12.5
 1 gem installed
 ~~~
@@ -45,7 +45,7 @@
 
     $ mkdir bundler_example && cd bundler_example
     $ bundle init
-
+    
 This will create `Gemfile` inside `bundler_example` folder:
 
 ~~~ ruby
@@ -84,7 +84,7 @@
 
 ***
 
-Learn more about `source` [here](/man/gemfile.5.html#GLOBAL-SOURCES).
+Learn more about `source` [here](/man/gemfile.5.html#GLOBAL-SOURCES). 
 
 ### Adding Gems
 
@@ -113,7 +113,7 @@
 or use this syntax:
 
 ~~~ ruby
-gem "rails", "~> 4.0.0" # which is same as gem "rails", ">= 4.0.0", "< 4.1.0"
+gem "rails", "~> 4.0.0" # which is same as gem "rails", ">= 4.0.0", "< 4.1.0" 
 gem "nokogiri", ">= 1.4.2"
 ~~~
 
@@ -154,13 +154,13 @@
           mini_portile2 (~> 2.1.0)
           pkg-config (~> 1.1.7)
         pkg-config (1.1.7)
-
+    
     PLATFORMS
       ruby
-
+    
     DEPENDENCIES
       nokogiri (>= 1.4.0)
-
+    
     BUNDLED WITH
        1.12.5
 
@@ -171,8 +171,8 @@
 For deployment you should use
 [`--deployment` option](/man/bundle-install.1.html#DEPLOYMENT-MODE):
 
-    bundle install --deployment
-
+    $ bundle install --deployment
+    
 This will install all dependencies to `./vendor/bundle`.
 
 To run this command, there are some requirements:
@@ -195,7 +195,7 @@
 This file is created/updated automatically when you use some of Bundler's commands
 (e.g. `bundle install` or `bundle update`) and you should check it into version control.
 
-We will use Gemfile.lock from previous chapter as an example.
+We will use Gemfile.lock from previous chapter as an example. 
 
     GEM
       remote: https://rubygems.org/
@@ -205,17 +205,17 @@
           mini_portile2 (~> 2.1.0)
           pkg-config (~> 1.1.7)
         pkg-config (1.1.7)
-
+    
     PLATFORMS
       ruby
-
+    
     DEPENDENCIES
       nokogiri (>= 1.4.0)
-
+    
     BUNDLED WITH
        1.12.5
 
-Let's break it down:
+Let's break it down: 
 
 * `GEM`
   * `remote` - source of gems
@@ -229,9 +229,9 @@
 
 Let's see examples first:
 
-    bundle exec rspec
-
-    bundle exec rails s
+    $ bundle exec rspec
+    
+    $ bundle exec rails s
 
 This will allow you to run command (`rspec` and `rails s` here) in current bundle context,
 making all gems in Gemfile available to `require` and use.
@@ -244,12 +244,12 @@
 
 Now let's update some gems. With `bundle outdated` we can list installed gems with newer versions available:
 
-    [kruczjak:~/git] % bundle outdated
+    $ bundle outdated
     Fetching gem metadata from https://rubygems.org/
     Fetching version metadata from https://rubygems.org/
     Fetching dependency metadata from https://rubygems.org/
     Resolving dependencies.......
-
+    
     Outdated gems included in the bundle:
       * nokogiri (newest 1.6.8, installed 1.6.7.2) in group "default"
 
@@ -259,7 +259,7 @@
 `bundle install` won't install newer version because it's locked in `Gemfile.lock` file.
 We must use `bundle update`.
 
-    [kruczjak:~/git] % bundle update
+    $ bundle update
     Fetching git://github.com/middleman/middleman-syntax.git
     Fetching gem metadata from https://rubygems.org/
     Fetching version metadata from https://rubygems.org/
@@ -267,11 +267,11 @@
     Resolving dependencies.....
     Installing nokogiri 1.6.8 (was 1.6.7.2) with native extensions
     Using i18n 0.7.0
-
+    
     ... (and more)
-
+    
     Bundle updated!
-
+    
 Using `bundle update` without any argument will try to update every gem to newest available version
 (restrained by `Gemfile`).
 
@@ -304,9 +304,9 @@
 ~~~
 $ git add Gemfile.lock
 ~~~
-
+ 
 * When checking out this repository on another development machine, run
-
+ 
 ~~~
 $ bundle install
 ~~~
@@ -345,4 +345,4 @@
 
 ### Running `git bisect` in projects using Bundler
 
-See [Git Bisect Guide](/guides/git_bisect.html).
+See [Git Bisect Guide](./git_bisect.html).

Why did you choose this fix out of the possible options?

Guides for v1.15 are the latest ones compatible with Ruby 1.8 while ones for v1.16 were updated with Ruby 1.9 hash notation in PR #404.

Signed-off-by: Takuya Noguchi [email protected]

[tnir]

@deivid-rodriguez I think we need to rescue Spanish translations (two files though) only for Bundler 1.15:

• https://bundler.io/es/v1.15/guides/bundler_setup.html
• https://bundler.io/es/v1.15/guides/bundler_sharing.html

That is why we need this PR instead of squashing everything in Guides one time suggested in #628. Thoughts?

[deivid-rodriguez]

I'm not fully sure what you mean. Is it that these two guides only exist in 1.15 or below and need to be updated?

[tnir]

These two es translation exist only in 1.15, but I would say I cannot check if they are up to date and so compatible with en and pl for Bundler 2.3.

That's why I think this PR is needed besides #628.

[deivid-rodriguez]

Where are these translated pages linked from? We don't have any locale switcher or automatic language selection, so in my opinion it makes no sense to keep these translated pages, at least for now.

[tnir]

Internal links for humans are not found but https://bundler.io/sitemap.xml has and thus Google has. https://www.google.com/search?q=site%3Abundler.io+es

I am not sure if these translated pages are preferred to ones in English for Spaniards and people in Spain though 😀

[tnir]

@deivid-rodriguez As per #625 (comment), I updated this PR to align with the following discussion:

[...] I think for now, before we implement the other steps, I'd rather keep the list of links but change them to be redirects to [...] the 1.15 guide [...]

Also updated the description of the PR.

[deivid-rodriguez]

I am not sure if these translated pages are preferred to ones in English for Spaniards and people in Spain though 😀

I think they are not, to be honest.

In any case, I think this PR is good to go now.

[deivid-rodriguez]

Just one minor comment.

[deivid-rodriguez]

Seems like a good start, let's do it!

[tnir]

Thank you.

[deivid-rodriguez]

Does #641 unblock unifying all guides into a section not dependent on the version of Bundler?

[tnir]

creating_gem for 1.12, 1.13, 1.14 and en and pl looks good:

• https://bundler.io/pl/v1.12/guides/creating_gem.html
  • => https://bundler.io/pl/v1.15/guides/creating_gem.html

but using_bundler_in_applications is not correctly redirected 😭 :

• https://bundler.io/v1.12/guides/using_bundler_in_applications.html
• => https://bundler.io/v1.12/guides/v1.15/using_bundler_in_applications.html

So weird...

[tnir]

Does #641 unblock unifying all guides into a section not dependent on the version of Bundler?

@deivid-rodriguez #641 could be an option but I had a different plan to avoid an extra copy 😀

[deivid-rodriguez]

Ok, what's your plan then? And what do you mean by "extra copy"? My idea with updating the Spanish guides (the only ones who had fallen behind) is that after that we could discard all old versions of guides and unify everything.

[tnir]

[...] what do you mean by "extra copy"?

I just meant we should avoid unnecessary additions like "+169" in #641:

As #641 was already merged, there is no more problem now. I hope I take more steps to improve the system! 🎸