-
Notifications
You must be signed in to change notification settings - Fork 282
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
Perhaps rollbar should be at 1.x.x? #119
Comments
Hey @jcwilk - thanks for asking about this. We've been holding off on 1.0 because we have some significant API changes that we're planning, and 1.0 seems like a good time to release them. But it might be best to go 1.0 now and save that for 2.0... We have been treating minor version changes (0.12.20 -> 0.13.0) as "breaking". If you pin yourself to a minor version then you should be safe, e.g.
I also think you bring up a good case for 1.0; we'll discuss that internally. |
Thanks so much for the quick reply! I'll follow your advice and adjust our pinned versions accordingly for now. |
We decided we buy your argument about 1.0. Thanks for bringing it up! 1.0.0 was released on 7/16/14 in 487acba . |
Happy to help :D Thanks |
🍻 |
We love Rollbar and use it for everything, but all of our branches suddenly started failing on CI last night because a breaking change (Rollbar.report_exception returning "disabled" instead of a hash in test... Granted, it's just in test, but it was a significant disruption to our development flow across the team) was released with only a minor bump due to rollbar being on
0.x.x
.Not sure if you guys are trying to follow Semantic Versioning, but according to http://semver.org/ :
"How do I know when to release 1.0.0?
If your software is being used in production, it should probably already be 1.0.0. If you have a stable API on which users have come to depend, you should be 1.0.0. If you're worrying a lot about backwards compatibility, you should probably already be 1.0.0."
Given that you have 46 forks of the project and many paying customers using your gem in production, it seems like it's due to be
>= 1.0.0
. If it was, we'd be able to more accurately lock the gem by a specific version range, and when you wanted to release breaking changes you'd be able to bump the major.Thoughts?
The text was updated successfully, but these errors were encountered: