Skip to content
New issue

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

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Correctly handle beta and pre gems #12

Open
joonty opened this issue Nov 11, 2015 · 2 comments
Open

Correctly handle beta and pre gems #12

joonty opened this issue Nov 11, 2015 · 2 comments
Labels

Comments

@joonty
Copy link
Owner

joonty commented Nov 11, 2015

If a gem version is in beta or pre (the final part of the version can be any string, I think), pessimize doesn't currently work correctly. For example, the debugger2 gem has version "1.0.0.beta2", but using the constraint "~> 1.0" doesn't seem to include beta gems.

There are two ways round this:

  1. Don't add constraints to beta/pre gems, i.e. gem "debugger2"
  2. Specify the exact version for beta/pre gems, i.e. gem "debugger2", "1.0.0.beta2"

I'm leaning towards 1, as it's not ideal to lock down a gem version to always be in beta.

@joonty joonty added the bug label Nov 11, 2015
@LimeBlast
Copy link

Maybe, if the script comes across such a gem, you could add some text to the output explaining this issue, and let the user choose what's best for them.

Something in beta is way more likely to have breaking changes, but it always depends on the context, and an informed user can make a decision based their own context.

I think it might also be worth stressing the pros and cons of each approach, i.e. the first one will allow for breaking changes, but you'll always be up to date, while the second one will always work as it'll never change - or something like that.

@joonty
Copy link
Owner Author

joonty commented Nov 11, 2015

Nice idea, thanks @LimeBlast.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants