-
Notifications
You must be signed in to change notification settings - Fork 16
Feature request: omitting patch-level from RVM Ruby selection #64
Comments
Yeah this seems like a great idea. Probably the easiest way to do this would be to just add the fuzzy matching without changing the UI at all. Once this is done and proven, I think it mite be a good idea to add place holders for the normalised versions and see what others think. I can certainly see how this would help as updates to various systems can provide slightly different patch releases, this is certainly the case with ubuntu. And yeah depending on how familiar you are with Java I am happy to help with a PR. |
Cool. Yeah, I'm very comfortable with Java, although Ruby has sucked out some of my desire to write Java ;) The part I'm stuck on, from a design perspective, is how we go from the patch version I'm thinking this challenge has two important components:
I'd love to hear your thoughts on it. I will probably start hacking away at this, too. I might be overstating the problem. |
Awesome you're taking a look ted ! I think it is important to register the discovered rubies under multiple I.e. Register as: This will let plans choose their level of preference in the task config.
|
Gday Ted I had a look at those files you linked to in the RVM project and they actually look pretty easy to persist as meta data within the project. So on load the project would load a Map of synonyms, with their matches stored in a list, then the UI bindings would merge that with the actual. I personally would just as suggested select 1.9.3 or 2.0.0 in 99% of cases.. Likewise when it comes time to locate the version it would use a routine to walk through the options based on information in the map and some simple file system checks. |
Hi, thanks for the work on this plugin. I work with @eddiewebb and use this plugin daily for our builds.
I'd really like to see a change in the way Rubies are selected, to only select major versions. For example, I'd like to have the equivalent of
rvm use jruby
orrvm use 2.0.0
. The current behavior is closer torvm use jruby-1.7.10
orrvm use 2.0.0-p353
. We don't really gain much by specifying which Ruby to use at that low of a level, so it would be nice to make patch-level selection optional.We have a semi-large build farm and managing the minor patch levels of installed Rubies adds overhead we'd do well to eliminate. It would also give us more reliable builds. I think #62 might be caused by the plan specifying a Ruby that isn't installed; e.g., plan requires 2.0.0-p353 but only 2.0.0-p195 is installed, or requires jruby-1.7.10 but 1.7.5 is installed.
Gemsets should probably be supported at the major-release level, too, so you can specify jruby@rails4 or 2.0.0@rails4api, again, without patch level.
I'm open to collaborating on or sending a PR for this feature, but wanted to run it by you first.
Thanks!
The text was updated successfully, but these errors were encountered: