Rewrite bundler_sharing guide (en, es) from HAML to Markdown

source/guides/bundler_sharing.html.md

@@ -0,0 +1,53 @@
+---
+title: How to package and share code using a Gemfile
+---
+## How to package and share code using a Gemfile
+<a name="sharing"></a>
+
+### Checking Your Code into Version Control
+<a name="checking-your-code-into-version-control"></a>
+
+After developing your application for a while, check in the application together with the
+`Gemfile` and `Gemfile.lock` snapshot. Now, your repository has a
+record of the exact versions of all of the gems that you used the last time you know for
+sure that the application worked. Keep in mind that while your `Gemfile`
+lists only three gems (with varying degrees of version strictness), your application
+depends on dozens of gems, once you take into consideration all of the implicit
+requirements of the gems you depend on.
+
+This is important: **the `Gemfile.lock` makes your application a single
+package of both your own code and the third-party code it ran the last time you know for
+sure that everything worked**. Specifying exact versions of the third-party code
+you depend on in your `Gemfile` would not provide the same guarantee, because
+gems usually declare a range of versions for their dependencies.
+
+The next time you run `bundle install` on the same machine, bundler will see
+that it already has all of the dependencies you need and skip the installation process.
+
+Do not check in the `.bundle` directory or any of the files inside it. Those
+files are specific to each particular machine and are used to persist installation options
+between runs of the `bundle install` command.
+
+If you have run `bundle pack`, the gems (although not the git gems) required
+by your bundle will be downloaded into `vendor/cache`. Bundler can run without
+connecting to the internet (or the RubyGems server) if all the gems you need are present
+in that folder and checked in to your source control. This is an **optional**
+step and not recommended due to the increase in size of your source control repository.
+
+### Sharing Your Application With Other Developers
+<a name="sharing-your-application-with-other-developers"></a>
+
+When your co-developers (or you on another machine) check out your code, it will come
+with the exact versions of all the third-party code your application used on the machine
+that you last developed on (in the `Gemfile.lock`). When **they** run
+`bundle install`, bundler will find the `Gemfile.lock` and skip
+the dependency resolution step. Instead, it will install all of the same gems that you
+used on the original machine.
+
+In other words, you don't have to guess which versions of the dependencies you should
+install. In the example we've been using, even though `rack-cache` declares a
+dependency on `rack >= 0.4`, we know for sure it works with `rack
+1.5.2`. Even if the Rack team releases `rack 1.5.3`, bundler will
+always install `1.5.2`, the exact version of the gem that we know works. This
+relieves a large maintenance burden from application developers because all machines
+always run the exact same third-party code.

source/localizable/guides/bundler_sharing.es.html.md

@@ -0,0 +1,52 @@
+---
+title: Compartiendo su código
+---
+## Cómo paquetizar y compartir código usando un Gemfile
+<a name="sharing"></a>
+
+### Chequeando su código en su sistema de control de versiones
+<a name="checking-your-code-into-version-control"></a>
+
+Después de desarrollar su aplicación por un tiempo, chequee su código en su sistema de
+control de versiones con el `Gemfile` y el `Gemfile.lock`.
+Ahora, su repositorio tiene un registro de las versiones exactas de todas las gemas que usó la
+última vez que usted sabe que la aplicación sirvió. Tenga en mente que mientras su `Gemfile`
+lista solamente tres gemas (con diferente grados de rigor de versión), su aplicación
+depende de muchas gemas cuando se considera todos los requisitos implícitos de todas las gemas
+que dependen en unas de otras.
+
+Esto es importante: **el `Gemfile.lock`** contiene su código y también código de terceros.
+El**`Gemfile.lock`** hace que su aplicación sea un paquete singular
+que asegura que su aplicación ejecutó con éxito la última vez que corrió el código.
+Especificando versiones exáctas del código de terceros que uno depende de su
+`Gemfile` no proveería la misma garantía, porque gemas usualmente declaran
+un rango de versiones para sus dependencias.
+
+La próxima vez que ejecuta `bundle install` en la misma máquina, bundler va a ver
+que ya tiene todas las dependencias necesarias, y va a omitir el proceso de instalación.
+
+No chequee el directorio `.bundle`, o ningunos de los archivos dentro de él.
+Esos archivos son específicos para cada máquina, y se usan para persistir opciones de
+instalación entre diferentes instancias de ejecutación del comando `bundle install`.
+
+Si ha ejecutado `bundle pack`, las gemas (pero no las gemas de git) necesitadas
+por su bundle van a estar descargadas en `vendor/cache`. Bundler puede correr sin
+conectarse al internet (o al servidor RubyGems) si todas las gemas que necesita ya están presentes
+en ese directorio y están chequeadas en su sistema de control de versiones.
+
+### Compartiendo su aplicación con otros desarrolladores
+<a name="sharing-your-application-with-other-developers"></a>
+
+Cuando otros desarrolladores (o usted mismo en otra máquina) chequean su código,
+va a venir con las versiones exáctas de todo el código de terceros que su aplicación
+usó en la máquina que usó más reciéntemente para desarrollar (en el `Gemfile.lock`).
+Cuando <em>otros</em> ejecuten `bundle install`, bundler va a encontrar el
+`Gemfile.lock` y va a omitir el paso de resolver dependencias.
+
+En otras palabras, no va a adivinar cuales versiones de las dependencias debería
+instalar. En los ejemplos que hemos usado, aunque `rack-cache` declara una
+dependencia en `rack >= 0.4`, sabemos que definitivamente trabaja con `rack
+1.5.2`. Aunque Rack lanzaría `rack 1.5.3`, bundler va a siempre instalar
+`1.5.2`, la version exácta de la gema que sabemos que funciona. Esto
+alivia una gran parte de la carga de mantenimiento de desarrolladores de aplicación, porque
+todas las máquinas siempre ejecutarán el mismo código de terceros.