Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Granular Updates Proposal #1735

cwgem opened this Issue Mar 27, 2013 · 4 comments


None yet
3 participants

cwgem commented Mar 27, 2013

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.



envygeeks commented Mar 27, 2013

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.


mpapis commented Mar 27, 2013

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?)


mpapis commented Apr 10, 2013

scheduling to 2.0 - feel free to move it to 1.20 if you have time to implement it earlier.


mpapis commented Apr 14, 2013

added to plan, closing as this is issue tracker for RVM 1.x

@mpapis mpapis closed this Apr 14, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment