You can clone with
No one assigned
We often get a lot of bugs where the user is on the stable branch and has to wait for the next release before a fix for their issue is usable. They could update to head, but that's a fast moving target which has the potential to introduce one issue while solving the core issue.
With that in mind I'm wondering if we should implement an rvm patch [ids] type command which essentially is given a list of commit ids (ala git cherry pick), will download them as a patch (in GitHub you can attach .patch at the end of a commit to get a patch file) and attempt to apply the patch (--dry-run) to rvm path. If all works well the patch is then applied and the user gets the changes applied specific to their fix. They can later update to the stable release when it comes out.
rvm patch [ids]
git cherry pick
I personally think it would be cleaner if we took a Debian style approach to life and worked in unstable branch and merge into head daily if it will go into 1.19.1 and then start releasing a stable point release weekly. This makes it so that we only have to change our flow, not the users flow and it should (if I assume right) work by default so they could do "rvm get unstable" for our moving target branch "rvm get head" for our working branch on 1.19.1 and "stable" for stable.
Edit: It also makes it so that all the old advice is not rendered irrelevant either.
Or we could focus on RVM2 and release small gems as often as it's needed ... this is feature request and those it will slow down progress for RVM2 ... we only went with autolibs feature in RVM1 because it was easier then supporting openssl compilation via rvm pkg.
We need to make RVM1 stable and stop working on new features, all feature requests should be rejected except stability/security related stuff or new versions updates as long as RVM2 is not marked stable - basically this removes need for that feature (for me).
As we are opensoure driven I leave it to you if you prefer to deliver this feature or help with RVM2 efforts.
(I hope I'm not to harsh?)
scheduling to 2.0 - feel free to move it to 1.20 if you have time to implement it earlier.
added to plan, closing as this is issue tracker for RVM 1.x