bullet_train 1.3.25 → 1.4.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: f08f50d147fb7c6e08833c2e5aa5eb06f8dabd3300cd877155f4dca51b84148a
-  data.tar.gz: ab7c997833b6b3b8ffb7d32ebec8e1259f9b08f420ed54b56f5184c4e13c2004
+  metadata.gz: a356bf776628bd7117355b5e70911db41a86840587a57aa3126681d8c29b0490
+  data.tar.gz: e7ffd1eabcbcc49000f2aee49d4a5454c624fa98040611db04772b587b245946
 SHA512:
-  metadata.gz: 6ab2e949af4f19461b29ad9d8df5c8cd3ee0a194c15de5550adba3454147c37999398f2db1151bdea8ed34819be7e697e926b7bc9f184f3bec12d04a119ae10e
-  data.tar.gz: 97039e1fe4a45618a8b03c3961982f52dd181f9174d193a29f99adaf061fbb73135edd4435281cc5fc306944828df3479641b785de60c0380c036f21001a28c5
+  metadata.gz: d31d5d44bfcbe47cd5f7e970d74001cd35b2c29dcecde1d024f6f7af3fd61c146db90727c7af3ba886f8662bb23e1aabdf5743316353e5fdd976237003e32cdd
+  data.tar.gz: 0723d0ec3dad3801f9d8fc7cd1303923d372971d524313b5af9d2192c18df9c5d1fb8d5057b1511f28f458e7431a700b6cbd79f219c4935c572923e18fe268fc

data/docs/upgrades/options.md

@@ -0,0 +1,90 @@
+# Options For Upgrading Your Bullet Train Application
+
+## Quick Links
+
+* [The YOLO Method (The original upgrade method)](/docs/upgrades/yolo.md)
+* [The Stepwise Method - For `1.4.0` and above](/docs/upgrades)
+* [Upgrade from any version to `1.4.0`](/docs/upgrades/yolo-140.md)
+* [Upgrade from any version to `1.3.0`](/docs/upgrades/yolo-130.md)
+* [Upgrade from `1.3.x` to `1.4.0`](/docs/upgrades/yolo-140.md)
+
+## About the upgrade process
+
+The vast majority of Bullet Train's functionality is distributed via Ruby gems, but those gems depend on certain
+hooks and initializers being present in the hosting application. Those hooks and initializers are provided by the
+[starter repository](https://github.com/bullet-train-co/bullet_train).
+
+Starting in mid-August of 2023 we began to iterate on how we publish gems and how we ensure that the starter repo
+will get the version of the gems that it expects.
+
+Starting with version `1.3.0` we began to explicitly update the starter repo every time that we released new
+versions of the Bullet Train gems. Unfortunately, at that time we were only making changes to `Gemfile.lock`
+which kind of hides the dependencies, and is often a source of merge conflicts that can be hard to sort out.
+
+Starting with version `1.4.0` we added explicit version numbers for all of the Bullet Train gems to `Gemfile`,
+which is less hidden and is not as prone to having merge conflicts as `Gemfile.lock`.
+
+As a result of these changes, there are a few different ways that you might choose to upgrade your application
+depending on which version you're currently on.
+
+## How to find your current version
+
+You can easily find your current version by running `bundle show | grep "bullet_train "`.
+
+For example:
+
+```
+$ bundle show | grep "bullet_train "
+  * bullet_train (1.3.20)
+```
+
+This app is on version `1.3.20`
+
+## How to upgrade
+
+Depending on what version you're starting on, and what version you want to get to, you have a few options.
+
+In general your two main options are:
+
+1. Upgrade directly from whatever version you happen to be on all the way to the latest published version.
+2. Do a series of stepwise upgrades from the version you're on to the version you want to get to.
+
+### Upgrade directly from any previous version to the latest version (aka The YOLO Method)
+
+This was the original upgrade method that Bullet Train used for many years. It's still a perfectly useable way of
+upgrading, though it feels a little... let's call it "uncontrolled" to some people. It can definitely lead to some
+hairy merge conflicts if you haven't updated in a long time.
+
+[Read more about The YOLO Method](/docs/upgrades/yolo.md)
+
+### Upgrade from `1.4.0` (or later) to any later version (aka The Standard Stepwise Method)
+
+This is the new standard upgrade method that we recommend. If you've ever upgraded a Rails app from version to version
+this process should feel fairly similar.
+
+[Read more about The Stepwise Method](/docs/upgrades)
+
+### Upgrade from any previous verison to version `1.4.0` (a modified YOLO)
+
+If you're on a version prior to `1.4.0` it can be a little tricky to do a stepwise upgrade to get to `1.4.0`. It's not
+impossible (see below), but if you're feeling lucky you might start with making an attempt to upgrade your app directly to `1.4.0`.
+
+[Read more about going directly to `1.4.0`](/docs/upgrades/yolo-140.md)
+
+### Upgrade from any previous verison to version `1.3.0` (and through the `1.3.x` line)
+
+Since we weren't tracking version numbers in `Gemfile` (only `Gemfile.lock`) it can be a little tricky to upgrade
+directly to `1.3.0`. With a few extra steps in the upgrade process it's (hopefully) not too terrible.
+
+[Read more about going directly to `1.3.0`](/docs/upgrades/yolo-130.md)
+
+### Upgrade from `1.3.x` to version `1.4.0`
+
+Once you make it to the end of the `1.3.x` line you only have one more step to get to the `1.4.0` branch. It's the
+same instructions as if you wanted to upgrade to `1.4.0` from any previous version.
+
+[Read more about going from `1.3.x` to `1.4.0`](/docs/upgrades/yolo-140.md)
+
+
+
+

data/docs/upgrades/yolo-130.md

@@ -0,0 +1,278 @@
+# Upgrading Your Bullet Train Application to Version `1.3.0` and through the `1.3.x` line
+
+<div class="rounded-md border bg-amber-100 border-amber-200 py-4 px-5 mb-3 not-prose">
+  <p class="text-sm text-amber-800 font-light mb-2">
+    If you're already on version <code>1.4.0</code> or later you should use
+    <a href="/docs/upgrades">The Stepwise Upgrade Method</a>
+  </p>
+  <p class="text-sm text-amber-800 font-light">
+    <a href="/docs/upgrades/options">Learn about other upgrade options.</a>
+  </p>
+</div>
+
+## Getting to `1.3.0`
+
+### 1. Make sure you're working with a clean local copy.
+
+```
+git status
+```
+
+If you've got uncommitted or untracked files, you can clean them up with the following.
+
+```
+# ⚠️ This will destroy any uncommitted or untracked changes and files you have locally.
+git checkout .
+git clean -d -f
+```
+
+### 2. Fetch the latest and greatest from the Bullet Train repository.
+
+```
+git fetch bullet-train
+git fetch --tags bullet-train
+```
+
+### 3. Create a new "upgrade" branch off of your main branch.
+
+```
+git checkout main
+git checkout -b updating-bullet-train-v1.3.0
+```
+
+### 4. Merge in the newest stuff from Bullet Train and resolve any merge conflicts.
+
+```
+git merge v1.3.0
+```
+
+It's quite possible you'll get some merge conflicts at this point. No big deal! Just go through and
+resolve them like you would if you were integrating code from another developer on your team. We tend
+to comment our code heavily, but if you have any questions about the code you're trying to understand,
+let us know on Discord!
+
+One of the files that's likely to have conflicts, and which can be the most frustrating to resolve is
+`Gemfile.lock`. Unfortunately there are important changes in that file that we'll want to preserve.
+Luckily there's a way to do it without having to resolve conflicts manually. We'll handle that in the
+next step. For now you can just skip the updates in that file:
+
+```
+git checkout HEAD -- Gemfile.lock
+```
+
+Once you've resolved all the conflicts go ahead and commit the changes.
+
+```
+git diff
+git add -A
+git commit -m "Upgrading Bullet Train."
+```
+
+### 5. Update `Gemfile`
+
+Now we need to handle the situation with `Gemfile.lock` that we side-stepped earlier. you should open
+up your `Gemfile` and find this block of gems:
+
+```ruby
+# BULLET TRAIN GEMS
+# This section is the list of Ruby gems included by default for Bullet Train.
+
+
+# Core packages.
+gem "bullet_train"
+gem "bullet_train-super_scaffolding"
+gem "bullet_train-api"
+gem "bullet_train-outgoing_webhooks"
+gem "bullet_train-incoming_webhooks"
+gem "bullet_train-themes"
+gem "bullet_train-themes-light"
+gem "bullet_train-integrations"
+gem "bullet_train-integrations-stripe"
+
+
+# Optional support packages.
+gem "bullet_train-sortable"
+gem "bullet_train-scope_questions"
+gem "bullet_train-obfuscates_id"
+```
+
+Replace that entire block with this block:
+
+```ruby
+# BULLET TRAIN GEMS
+# This section is the list of Ruby gems included by default for Bullet Train.
+
+# We use a constant here so that we can ensure that all of the bullet_train-*
+# packages are on the same version.
+BULLET_TRAIN_VERSION = "1.3.0"
+
+# Core packages.
+gem "bullet_train", BULLET_TRAIN_VERSION
+gem "bullet_train-super_scaffolding", BULLET_TRAIN_VERSION
+gem "bullet_train-api", BULLET_TRAIN_VERSION
+gem "bullet_train-outgoing_webhooks", BULLET_TRAIN_VERSION
+gem "bullet_train-incoming_webhooks", BULLET_TRAIN_VERSION
+gem "bullet_train-themes", BULLET_TRAIN_VERSION
+gem "bullet_train-themes-light", BULLET_TRAIN_VERSION
+gem "bullet_train-integrations", BULLET_TRAIN_VERSION
+gem "bullet_train-integrations-stripe", BULLET_TRAIN_VERSION
+
+# Optional support packages.
+gem "bullet_train-sortable", BULLET_TRAIN_VERSION
+gem "bullet_train-scope_questions", BULLET_TRAIN_VERSION
+gem "bullet_train-obfuscates_id", BULLET_TRAIN_VERSION
+
+# Core gems that are dependencies of gems listed above. Technically they
+# shouldn't need to be listed here, but we list them so that we can keep
+# verion numbers in sync.
+gem "bullet_train-fields", BULLET_TRAIN_VERSION
+gem "bullet_train-has_uuid", BULLET_TRAIN_VERSION
+gem "bullet_train-roles", BULLET_TRAIN_VERSION
+gem "bullet_train-scope_validator", BULLET_TRAIN_VERSION
+gem "bullet_train-super_load_and_authorize_resource", BULLET_TRAIN_VERSION
+gem "bullet_train-themes-tailwind_css", BULLET_TRAIN_VERSION
+```
+
+(We have to do this since we didn't start explicitly tracking versions until `1.4.0` and
+want to make sure that our gem versions match what the starter repo expects.)
+
+Then run `bundle update`
+
+Then go ahead and commit the changes.
+
+```
+git diff
+git add -A
+git commit -m "Upgrading Bullet Train gems."
+```
+
+### 5. Run Tests.
+
+```
+rails test
+rails test:system
+```
+
+If anything fails, investigate the failures and get things working again, and commit those changes.
+
+### 6. Merge into `main` and delete the branch.
+
+```
+git checkout main
+git merge updating-bullet-train-v1.3.0
+git push origin main
+git branch -d updating-bullet-train-v1.3.0
+```
+
+Alternatively, if you're using GitHub, you can push the `updating-bullet-train-v1.3.0` branch up and create a PR from it and let your CI integration do it's thing and then merge in the PR and delete the branch there. (That's what we typically do.)
+
+
+## Stepping to `1.3.x`
+
+Before doing this you should have already followed the instructions above to get to version `1.3.0`.
+
+For purposes of this example we'll assume that you're stepping up from `1.3.0` to `1.3.1`.
+
+### 1. Make sure you're working with a clean local copy.
+
+```
+git status
+```
+
+If you've got uncommitted or untracked files, you can clean them up with the following.
+
+```
+# ⚠️ This will destroy any uncommitted or untracked changes and files you have locally.
+git checkout .
+git clean -d -f
+```
+
+### 2. Fetch the latest and greatest from the Bullet Train repository.
+
+```
+git fetch bullet-train
+git fetch --tags bullet-train
+```
+
+### 3. Create a new "upgrade" branch off of your main branch.
+
+```
+git checkout main
+git checkout -b updating-bullet-train-v1.3.1
+```
+
+### 4. Merge in the newest stuff from Bullet Train and resolve any merge conflicts.
+
+```
+git merge v1.3.1
+```
+
+It's quite possible you'll get some merge conflicts at this point. No big deal! Just go through and
+resolve them like you would if you were integrating code from another developer on your team. We tend
+to comment our code heavily, but if you have any questions about the code you're trying to understand,
+let us know on Discord!
+
+One of the files that's likely to have conflicts, and which can be the most frustrating to resolve is
+`Gemfile.lock`. Unfortunately there are important changes in that file that we'll want to preserve.
+Luckily there's a way to do it without having to resolve conflicts manually. We'll handle that in the
+next step. For now you can just skip the updates in that file:
+
+```
+git checkout HEAD -- Gemfile.lock
+```
+
+Once you've resolved all the conflicts go ahead and commit the changes.
+
+```
+git diff
+git add -A
+git commit -m "Upgrading Bullet Train."
+```
+
+### 5. Update `Gemfile`
+
+Now we need to handle the situation with `Gemfile.lock` that we side-stepped earlier. you should open
+up your `Gemfile` and find this line:
+
+```ruby
+BULLET_TRAIN_VERSION = "1.3.0"
+```
+
+Update that line with the new version you're moving to:
+
+```ruby
+BULLET_TRAIN_VERSION = "1.3.1"
+```
+
+(We have to do this since we didn't start explicitly tracking versions until `1.4.0` and
+want to make sure that our gem versions match what the starter repo expects.)
+
+Then run `bundle update`
+
+Then go ahead and commit the changes.
+
+```
+git diff
+git add -A
+git commit -m "Upgrading Bullet Train gems."
+```
+
+### 5. Run Tests.
+
+```
+rails test
+rails test:system
+```
+
+If anything fails, investigate the failures and get things working again, and commit those changes.
+
+### 6. Merge into `main` and delete the branch.
+
+```
+git checkout main
+git merge updating-bullet-train-v1.3.1
+git push origin main
+git branch -d updating-bullet-train-v1.3.1`
+```
+
+Alternatively, if you're using GitHub, you can push the `updating-bullet-train-v1.3.1` branch up and create a PR from it and let your CI integration do it's thing and then merge in the PR and delete the branch there. (That's what we typically do.)

data/docs/upgrades/yolo-140.md

@@ -0,0 +1,94 @@
+# Upgrading Your Bullet Train Application to Version `1.4.0`
+
+<div class="rounded-md border bg-amber-100 border-amber-200 py-4 px-5 mb-3 not-prose">
+  <p class="text-sm text-amber-800 font-light mb-2">
+    If you're already on version <code>1.4.0</code> or later you should use
+    <a href="/docs/upgrades">The Stepwise Upgrade Method</a>
+  </p>
+  <p class="text-sm text-amber-800 font-light">
+    <a href="/docs/upgrades/options">Learn about other upgrade options.</a>
+  </p>
+</div>
+
+## Getting to `1.4.0`
+
+### 1. Make sure you're working with a clean local copy.
+
+```
+git status
+```
+
+If you've got uncommitted or untracked files, you can clean them up with the following.
+
+```
+# ⚠️ This will destroy any uncommitted or untracked changes and files you have locally.
+git checkout .
+git clean -d -f
+```
+
+### 2. Fetch the latest and greatest from the Bullet Train repository.
+
+```
+git fetch bullet-train
+git fetch --tags bullet-train
+```
+
+### 3. Create a new "upgrade" branch off of your main branch.
+
+```
+git checkout main
+git checkout -b updating-bullet-train-v1.4.0
+```
+
+### 4. Merge in the newest stuff from Bullet Train and resolve any merge conflicts.
+
+```
+git merge v1.4.0
+```
+
+It's quite possible you'll get some merge conflicts at this point. No big deal! Just go through and
+resolve them like you would if you were integrating code from another developer on your team. We tend
+to comment our code heavily, but if you have any questions about the code you're trying to understand,
+let us know on Discord!
+
+One of the files that's likely to have conflicts, and which can be the most frustrating to resolve is
+`Gemfile.lock`. You can try to sort it out by hand, or you can checkout a clean copy and then let bundler
+generate a new one that matches what you need:
+
+```
+git checkout HEAD -- Gemfile.lock
+bundle update
+```
+
+If you choose to sort out `Gemfile.lock` by hand it's a good idea to run `bundle install` just to make
+sure that your `Gemfile.lock` agrees with the new state of `Gemfile`.
+
+Once you've resolved all the conflicts go ahead and commit the changes.
+
+```
+git diff
+git add -A
+git commit -m "Upgrading Bullet Train."
+```
+
+### 5. Run Tests.
+
+```
+rails test
+rails test:system
+```
+
+If anything fails, investigate the failures and get things working again, and commit those changes.
+
+### 6. Merge into `main` and delete the branch.
+
+```
+git checkout main
+git merge updating-bullet-train-v1.3.0
+git push origin main
+git branch -d updating-bullet-train-v1.3.0
+```
+
+Alternatively, if you're using GitHub, you can push the `updating-bullet-train-v1.3.0` branch up and create a PR from it and let your CI integration do it's thing and then merge in the PR and delete the branch there. (That's what we typically do.)
+
+

data/docs/upgrades/yolo.md

@@ -0,0 +1,91 @@
+# The YOLO Approach To Upgrading Your Bullet Train Application
+
+<div class="rounded-md border bg-amber-100 border-amber-200 py-4 px-5 mb-3 not-prose">
+  <p class="text-sm text-amber-800 font-light mb-2">
+    Note: We don't really recommend using this method.
+    <a href="/docs/upgrades/options">Learn about other upgrade options.</a>
+  </p>
+  <p class="text-sm text-amber-800 font-light">
+    If you're already on version <code>1.4.0</code> or later you should use
+    <a href="/docs/upgrades">The Stepwise Upgrade Method</a>
+  </p>
+</div>
+
+## Pulling Updates from the Starter Repository
+
+There are times when you'll want to pull updates from the starter repository into your local application. Thankfully, `git merge` provides us with the perfect tool for just that. You can simply merge the upstream Bullet Train repository into your local repository. If you haven’t tinkered with the starter repository defaults at all, then this should happen with no meaningful conflicts at all. Simply run your automated tests (including the comprehensive integration tests Bullet Train ships with) to make sure everything is still working as it was before.
+
+If you _have_ modified some starter repository defaults _and_ we also happened to update that same logic upstream, then pulling the most recent version of the starter repository should cause a merge conflict in Git. This is actually great, because Git will then give you the opportunity to compare our upstream changes with your local customizations and allow you to resolve them in a way that makes sense for your application.
+
+### 1. Make sure you're working with a clean local copy.
+
+```
+git status
+```
+
+If you've got uncommitted or untracked files, you can clean them up with the following.
+
+```
+# ⚠️ This will destroy any uncommitted or untracked changes and files you have locally.
+git checkout .
+git clean -d -f
+```
+
+### 2. Fetch the latest and greatest from the Bullet Train repository.
+
+```
+git fetch bullet-train
+```
+
+### 3. Create a new "upgrade" branch off of your main branch.
+
+```
+git checkout main
+git checkout -b updating-bullet-train
+```
+
+### 4. Merge in the newest stuff from Bullet Train and resolve any merge conflicts.
+
+```
+git merge bullet-train/main
+```
+
+It's quite possible you'll get some merge conflicts at this point. No big deal! Just go through and resolve them like you would if you were integrating code from another developer on your team. We tend to comment our code heavily, but if you have any questions about the code you're trying to understand, let us know on Discord!
+
+One of the files that's likely to have conflicts, and which can be the most frustrating to resolve is
+`Gemfile.lock`. You can try to sort it out by hand, or you can checkout a clean copy and then let bundler
+generate a new one that matches what you need:
+
+```
+git checkout HEAD -- Gemfile.lock
+bundle update
+```
+
+If you choose to sort out `Gemfile.lock` by hand it's a good idea to run `bundle install` just to make
+sure that your `Gemfile.lock` agrees with the new state of `Gemfile`.
+
+Once you've resolved all the conflicts go ahead and commit the changes.
+
+```
+git diff
+git add -A
+git commit -m "Upgrading Bullet Train."
+```
+
+### 5. Run Tests.
+
+```
+rails test
+rails test:system
+```
+
+### 6. Merge into `main` and delete the branch.
+
+```
+git checkout main
+git merge updating-bullet-train
+git push origin main
+git branch -d updating-bullet-train
+```
+
+Alternatively, if you're using GitHub, you can push the `updating-bullet-train` branch up and create a PR from it and let your CI integration do it's thing and then merge in the PR and delete the branch there. (That's what we typically do.)

data/docs/upgrades.md

@@ -1,16 +1,40 @@
 # Upgrading Your Bullet Train Application
 
-## Upgrading the Framework
-
-The vast majority of Bullet Train's functionality is distributed via Ruby gems, so you can pull the latest updates by running `bundle update`.
+<div class="rounded-md border bg-amber-100 border-amber-200 py-4 px-5 mb-3 not-prose">
+  <h3 class="text-sm text-amber-800 font-light mb-2">
+    Note: These ugrade steps have recently changed.
+  </h3>
+  <p class="text-sm text-amber-800 font-light mb-2">
+    These instructions assume that you're doing a stepwise upgrade on an app that's already on version <code>1.4.0</code> or later.
+  </p>
+  <p class="text-sm text-amber-800 font-light">
+    <a href="/docs/upgrades/options">Learn about other upgrade options.</a>
+  </p>
+</div>
+
+## The Stepwise Upgrade Method
+
+This method will ensure that the version of the Bullet Train gems that your app uses will stay in sync with the appliation framework provided by the starter repo.
+If you've ever upgraded a Rails app from version to version this process should feel fairly similar.
 
 ## Pulling Updates from the Starter Repository
 
-There are times when you'll want to pull updates from the starter repository into your local application. Thankfully, `git merge` provides us with the perfect tool for just that. You can simply merge the upstream Bullet Train repository into your local repository. If you haven’t tinkered with the starter repository defaults at all, then this should happen with no meaningful conflicts at all. Simply run your automated tests (including the comprehensive integration tests Bullet Train ships with) to make sure everything is still working as it was before.
+There are times when you'll want to update Bullet Train gems and pull updates from the starter repository into your local application.
+Thankfully, `git merge` provides us with the perfect tool for just that. You can simply merge the upstream Bullet Train repository into
+your local repository. If you haven’t tinkered with the starter repository defaults at all, then this should happen with no meaningful
+conflicts at all. Simply run your automated tests (including the comprehensive integration tests Bullet Train ships with) to make sure
+everything is still working as it was before.
+
+If you _have_ modified some starter repository defaults _and_ we also happened to update that same logic upstream, then pulling the most
+recent version of the starter repository should cause a merge conflict in Git. This is actually great, because Git will then give you the
+opportunity to compare our upstream changes with your local customizations and allow you to resolve them in a way that makes sense for
+your application.
+
+### 1. Decide which version you want to upgrade to
 
-If you _have_ modified some starter repository defaults _and_ we also happened to update that same logic upstream, then pulling the most recent version of the starter repository should cause a merge conflict in Git. This is actually great, because Git will then give you the opportunity to compare our upstream changes with your local customizations and allow you to resolve them in a way that makes sense for your application.
+For the purposes of these instructions we'll assume that you're on version `1.4.0` and are going to upgrade to version `1.4.1`.
 
-### 1. Make sure you're working with a clean local copy.
+### 2. Make sure you're working with a clean local copy.
 
 ```
 git status
@@ -24,47 +48,71 @@ git checkout .
 git clean -d -f
 ```
 
-### 2. Fetch the latest and greatest from the Bullet Train repository.
+### 3. Fetch the latest and greatest from the Bullet Train repository.
 
 ```
 git fetch bullet-train
+git fetch --tags bullet-train
 ```
 
-### 3. Create a new "upgrade" branch off of your main branch.
+### 4. Create a new "upgrade" branch off of your main branch.
+
+It can be handy to include the version number that you're moving to in the branch name.
 
 ```
 git checkout main
-git checkout -b updating-bullet-train
+git checkout -b updating-bullet-train-1.4.1
 ```
 
-### 4. Merge in the newest stuff from Bullet Train and resolve any merge conflicts.
+### 5. Merge in the newest stuff from Bullet Train and resolve any merge conflicts.
+
+Each version of the starter repo is tagged, so you can merge in the tag from the upstread repo.
 
 ```
-git merge bullet-train/main
+git merge v1.4.1
 ```
 
-It's quite possible you'll get some merge conflicts at this point. No big deal! Just go through and resolve them like you would if you were integrating code from another developer on your team. We tend to comment our code heavily, but if you have any questions about the code you're trying to understand, let us know on Discord!
+It's quite possible you'll get some merge conflicts at this point. No big deal! Just go through and
+resolve them like you would if you were integrating code from another developer on your team. We tend
+to comment our code heavily, but if you have any questions about the code you're trying to understand,
+let us know on [Discord!](https://discord.gg/bullettrain)
+
+One of the files that's likely to have conflicts, and which can be the most frustrating to resolve is
+`Gemfile.lock`. You can try to sort it out by hand, or you can checkout a clean copy and then let bundler
+generate a new one that matches what you need:
+
+```
+git checkout HEAD -- Gemfile.lock
+bundle update
+```
+
+If you choose to sort out `Gemfile.lock` by hand it's a good idea to run `bundle install` just to make
+sure that your `Gemfile.lock` agrees with the new state of `Gemfile`.
+
+Once you've resolved all the conflicts go ahead and commit the changes.
 
 ```
 git diff
 git add -A
-git commit -m "Upgrading Bullet Train."
+git commit -m "Upgrading Bullet Train to v1.4.1."
 ```
 
-### 5. Run Tests.
+### 6. Run Tests.
 
 ```
 rails test
 rails test:system
 ```
 
-### 6. Merge into `main` and delete the branch.
+### 7. Merge into `main` and delete the branch.
 
 ```
 git checkout main
-git merge updating-bullet-train
+git merge updating-bullet-train-1.4.1
 git push origin main
-git branch -d updating-bullet-train
+git branch -d updating-bullet-train-1.4.1
 ```
 
-Alternatively, if you're using GitHub, you can push the `updating-bullet-train` branch up and create a PR from it and let your CI integration do it's thing and then merge in the PR and delete the branch there. (That's what we typically do.)
+Alternatively, if you're using GitHub, you can push the `updating-bullet-train-1.4.1` branch up and create a
+PR from it and let your CI integration do it's thing and then merge in the PR and delete the branch there.
+(That's what we typically do.)

data/lib/bullet_train/version.rb

@@ -1,3 +1,3 @@
 module BulletTrain
-  VERSION = "1.3.25"
+  VERSION = "1.4.0"
 end

data/lib/tasks/bullet_train_tasks.rake

@@ -295,7 +295,7 @@ namespace :bullet_train do
             end
           elsif flag == "--reset"
             if line.match?(/bullet_train/)
-              line.gsub!(/,.*$/, "")
+              line.gsub!(/,.*$/, ", BULLET_TRAIN_VERSION")
             end
             puts "Resetting '#{package}' package in the Gemfile...".blue
           end

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: bullet_train
 version: !ruby/object:Gem::Version
-  version: 1.3.25
+  version: 1.4.0
 platform: ruby
 authors:
 - Andrew Culver
@@ -745,6 +745,10 @@ files:
 - docs/trademark.md
 - docs/tunneling.md
 - docs/upgrades.md
+- docs/upgrades/options.md
+- docs/upgrades/yolo-130.md
+- docs/upgrades/yolo-140.md
+- docs/upgrades/yolo.md
 - docs/webhooks/incoming.md
 - docs/webhooks/outgoing.md
 - docs/zapier.md