Feature Proposal: Isolated bundle directory per release

Background

In the current implementation, installed gems are stored in a shared directory.

https://github.com/sonots/capistrano-bundle_rsync/blob/9635277f7af2f5d96133c046539f10ca439129e6/lib/capistrano/bundle_rsync/bundler.rb#L47

https://github.com/sonots/capistrano-bundle_rsync/blob/9635277f7af2f5d96133c046539f10ca439129e6/lib/capistrano/bundle_rsync/bundler.rb#L60

This architecture causes issues when a gem needs to be rebuilt on the build machine.

For example, when using a gem like mysql2 which depends on libmysqlclient.so, we may need to rebuild it to link against a different version of the library. In such cases, if we rebuild the gem on the build machine and then rsync it to the destination, the existing gem files in the shared directory are overwritten while they are still being referenced by running Ruby processes. This can lead to unexpected behavior or application crashes.

Proposal

To avoid such problems, I propose adding a new option: bundle_rsync_isolated_bundle.

When this option is set to true, the installed gems will be rsynced directly into each release directory (e.g., releases/20260121043951/vendor/bundle) instead of the shared directory.

This ensures that running Ruby processes remain unaffected by new releases until the symlink is switched.

Notes

• Naming: bundle_rsync_isolated_bundle is a placeholder; I'm open to better naming suggestions.
• Customization: We might want an additional option like bundle_rsync_isolated_bundle_path to specify the rsync destination path.
• Performance: We can maintain fast deployment speeds by utilizing hardlink copies (similar to the approach discussed in #38).

Start with lib/capistrano/bundle_rsync/bundler.rb at the linked lines 47 and 60 to understand how the shared bundle directory is selected and rsynced. Trace the release and shared paths, then define how the new option should place bundles in each release while preserving the existing behavior by default. Done means isolated releases no longer overwrite gems used by running processes, with naming and path customization decisions resolved.