In my opinion, some things should never change. It's an attribute of the language. If Groovy is following semver, backwards compatibility should be broken only in 3.x, and in my mind, you should only break backwards compatibility for things widely considered broken or for very major improvements to the language. By widely considered broken, I mean functionality where everyone assumes it's really supposed to do X but it actually does Y. When you read a list of breaking changes everyone should think for each one "oh I thought it already did that" or "finally, it works the way it should". Then there is the category similar to what JDK 9 is doing with changing/hiding internal classes, at least you knew it was a risk going into using that code. But even with that, look at how much contention that has caused around the Unsafe class for example. Another example is Firefox's electrolysis project to make Firefox multi-process, it's something that had to be done but it took years to make the change and breaks everyone. Java and Firefox are massive communities strong enough to handle that. I don't think Groovy is strong enough to handle that or a "Python 3" type situation.
I don't think you want to ever change basic things about Groovy like methods such as "with", it would break huge amounts of programs in a way that is very hard to test or verify. If you do that, you might as well just call it a different language at that point. Even things like 1/2 = 0.5 and using BigDecimal by default will just have to stay "forever" even if not everyone likes it. Jason -----Original Message----- On 06.07.2016 16:24, Suderman Keith wrote: > -1 to a breaking change (in 2.5 or 3.0). I agree with Jason, breaking > changes only for methods that are widely considered to be broken. if no breaking changes even in a new major version, then when? ---------------------------------------------------------------------- This email message and any attachments are for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message and any attachments.
