2 ms·

> the deprecation warnings are part of a standard of making what breaking changes do occur easier to handle, I don't think I'd agree with removing them What's

> the deprecation warnings are part of a standard of making what breaking changes do occur easier to handle, I don't think I'd agree with removing them What's wrong with an error that has the deprecation warning in, for the version that it breaks? I'm all for being informed, I just don't agree that it has to be baked into an interpreter and shown to me every time I run it. Write a blog post, put it in the change log or the README, I read those as I do the logs where it's incredibly irritating. And thanks for the tip about the gem.

jrochkind1 5y ago
> What's wrong with an error that has the deprecation warning in, for the version that it breaks? I don't understand what you mean? Isn't that what happened? > Write a blog post, put it in the change log or the README So, a) not everyone will see that, but b) that doesn't help you find anywhere in your code (possibly including in dependencies) that will break when you upgrade ruby, which you need to do. But I agree it can be annoying when there isn't anything you can do about it or you aren't ready to do anything about it. One way that might help is allowing you to toggle such warnings on or off. That third party gem that does allow you to do that albeit a bit hackily. Anyway, if you move to another language, come back after a couple years and let us know if you were more or less happy with their breaking change scenarios! :)
- brigandish 5y ago
  > > What's wrong with an error that has the deprecation warning in, for the version that it breaks? > I don't understand what you mean? Isn't that what happened? There are no errors in a version preceding the change, only warnings. There will be errors and possibly warnings in a version after the change. I don't want to see this stuff prior to upgrade. > a) not everyone will see that Why is that the problem of everyone else? They should take their job more seriously and read the change log. > b) that doesn't help you find anywhere in your code (possibly including in dependencies) that will break when you upgrade ruby, which you need to do. No, running it under the new version will. If there's a need to be ready ahead of time then, for example, the Ruby team could add these warnings as a compile time flag. They had a compile time flag to remove the warnings in a previous release, so it can be done. > Anyway, if you move to another language, come back after a couple years and let us know if you were more or less happy with their breaking change scenarios! :) I'm enjoying Crystal, for many reasons, and I'll be looking at Elixir too. Not sure I can entirely replace Ruby with them but I don't use it for any new projects now.

jrochkind1 5y ago

> What's wrong with an error that has the deprecation warning in, for the version that it breaks? I don't understand what you mean? Isn't that what happened? > Write a blog post, put it in the change log or the README So, a) not everyone will see that, but b) that doesn't help you find anywhere in your code (possibly including in dependencies) that will break when you upgrade ruby, which you need to do. But I agree it can be annoying when there isn't anything you can do about it or you aren't ready to do anything about it. One way that might help is allowing you to toggle such warnings on or off. That third party gem that does allow you to do that albeit a bit hackily. Anyway, if you move to another language, come back after a couple years and let us know if you were more or less happy with their breaking change scenarios! :)

brigandish 5y ago
> > What's wrong with an error that has the deprecation warning in, for the version that it breaks? > I don't understand what you mean? Isn't that what happened? There are no errors in a version preceding the change, only warnings. There will be errors and possibly warnings in a version after the change. I don't want to see this stuff prior to upgrade. > a) not everyone will see that Why is that the problem of everyone else? They should take their job more seriously and read the change log. > b) that doesn't help you find anywhere in your code (possibly including in dependencies) that will break when you upgrade ruby, which you need to do. No, running it under the new version will. If there's a need to be ready ahead of time then, for example, the Ruby team could add these warnings as a compile time flag. They had a compile time flag to remove the warnings in a previous release, so it can be done. > Anyway, if you move to another language, come back after a couple years and let us know if you were more or less happy with their breaking change scenarios! :) I'm enjoying Crystal, for many reasons, and I'll be looking at Elixir too. Not sure I can entirely replace Ruby with them but I don't use it for any new projects now.