Um…
Can someone fix this mess?
Add the original method back into the class and use @Deprecated please. This is a real mess for anyone who uses this method for plugins, etc.
EDIT: Especially considering the nightly build of plugins is still broken.
Not to start a complete flame war, but this was a real rank armature maneuver.
I’m not a professional developer (i.e. do not program as a day job) and even I would know better than to just arbitrarily change a method name for a public API, especially after a stable release.
I’m wondering exactly how many people have downloaded one of my plugins and never given it a second chance because of this. Really disappointing, but… such is life, I guess.
Why are you developing your plugin against nightly/trunk? Trunk is known to be unstable, its basically what 3.1 is supposed to become and thus will contain breaking changes. We have a stable branch for such things. Given your second post I guess you know how you come across…
@normen said: Why are you developing your plugin against nightly/trunk? Trunk is known to be unstable, its basically what 3.1 is supposed to become and thus *will* contain breaking changes. We have a stable branch for such things. Given your second post I guess you know how you come across..
I am not… other are using nightly however. And a complete rename of a method in an API without using @Deprecated is just… um… wow.
EDIT: I am hoping I came across pissed. Because… I am and it is warranted in this case. This was discussed soon after it changed, and nothing was done to resolve it.
3.1 is a potentially breaking version. Third party APIs should have some strategy in place to be compatible with the existing stable and the future version (or nightly if they want to support nightly). This is just one of potentially hundreds of changes that might affect a third party library.
The reason it wasn’t @Deprecated is because anyone using it as named might have had subtle bugs in their code that they were unaware of. Simply marking it as deprecated was likely to go unnoticed.
@pspeed said: 3.1 is a potentially breaking version. Third party APIs should have some strategy in place to be compatible with the existing stable and the future version (or nightly if they want to support nightly). This is just one of potentially hundreds of changes that might affect a third party library.The reason it wasn’t @Deprecated is because anyone using it as named might have had subtle bugs in their code that they were unaware of. Simply marking it as deprecated was likely to go unnoticed.
I take it the people who were aware are simply screwed until the next release?
@t0neg0d said: I take it the people who were aware are simply screwed until the next release?
Yes, anyone who is using trunk can easily be screwed, thats why we warn about using it.
@normen said: Yes, anyone who is using trunk can easily be screwed, thats why we warn about using it.
So… what’s your strategy for the next release when all code using interpolate breaks?
Wait! I think I got this one:
TO BAD!
@normen said: Yes, anyone who is using trunk can easily be screwed, thats why we warn about using it.
Yes, i known that…too bad for me ^^, i just wanted to report that thing to Chris for the release day 
@t0neg0d said: So... what's your strategy for the next release when all code using interpolate breaks?Wait! I think I got this one:
TO BAD!
So… say we had added a @Deprecated mark. And we release 3.0.10 with that mark. And then we release 3.1 with the old method gone (after all thats what deprecating means). Does it go TO BAD then too? Yes it does. Everything goes TO BAD when its over.
So… to paraphrase @pspeed:
On the OFF CHANCE that some MIGHT NOT have understood how interpolate workd (even though the JavaDocs are specific about it), I changed the method name intentionally screwing the people who WERE paying attention.
Please let me know if I got this right.
@normen said: So.. say we had added a @Deprecated mark. And we release 3.0.10 with that mark. And then we release 3.1 with the old method gone (after all thats what deprecating means). Does it go TO BAD then too? Yes it does. Everything goes TO BAD when its over.
And yes… that would have given those leveraging the API a chance to plan a fix instead of just breaking code.
@normen said: So.. say we had added a @Deprecated mark. And we release 3.0.10 with that mark. And then we release 3.1 with the old method gone (after all thats what deprecating means). Does it go TO BAD then too? Yes it does. Everything goes TO BAD when its over.
Yes, no real solution i think…initial mistake…this code is in for years…it should be fix sooner or later :s
It make no sense to just add a @Deprecated and add the new one…local or not the method will do the same thing…it could be disconcerting…reguarding all the other math classes with that syntax.
Java still has deprecated methods from version one. I’m really unaware of any company that would deprecate a method and remove it the very next release. I think you sorta overstated that example.
@t0neg0d said: So... to paraphrase @pspeed:On the OFF CHANCE that some MIGHT NOT have understood how interpolate workd (even though the JavaDocs are specific about it), I changed the method name intentionally screwing the people who WERE paying attention.
Please let me know if I got this right.
No… We changed the method name because its misleading. And we didn’t put a deprecation mark as the change supposed to be released with 3.1 and “trunk” is NOT, I repeat, NOT a release.
3.1 btw will make you whine even more as SimpleApplication changes, some internal logic about shaders change and worst of all the whole project layout will change too… We will be prepared for a shitstorm from your side… But it will probably still take enough time until 3.1 is released so we can brace ourselves… Oh wait no, you will tell us on each commit to trunk what breaks for you…
Question: in what version are we allowed to break stuff? Policy-wise, 3.1 may break tons of stuff that an @Deprecated tag would not fix. It’s the whole point of the 3.0 to 3.1 version increase… stuff will change in non-compatible ways.
Also, having an interpolate() and an interpolateLocal() side-by-side would make the problem even worse, in my opinion because now it looks like there are two of them that act like all of the other XXLocal and XX methods. If I thought people actually read the javadocs then I wouldn’t have to post links to it 10 times a week.
Stuff will break. This is just one of those things. If a third party library wants to support trunk then it will have to have two different branches. Either today or tomorrow. That’s really what we’re arguing about. You’d rather wait until some future breaking change.
@normen said: No.. We changed the method name because its misleading. And we didn't put a deprecation mark as the change supposed to be released with 3.13.1 btw will make you whine even more as SimpleApplication changes, some internal logic about shaders change and worst of all the whole project layout will change too… We will be prepared for a shitstorm from your side… But it will probably still take enough time until 3.1 is released so we can brace ourselves… Oh wait no, you will tell us on each commit to trunk what breaks for you…
It funny watching you talk about what you find important this week.
Remember the days when you just about peeled your own face off of your skull when people would post code to the forum instead of “MAKING IT A PLUGIN!”. Some change happens and we haven’t seen a current nightly build of community plugins for what? A year now? And not a peep from you about posting code on the forums any more. And apparently, though, we all thought you breathed, ate and slept plugins, this became unimportant and here we are.
Go figure.
Maybe proper consideration for updating released code will become important at some point /shrug
P.S. I would also say that if you are simply scrapping the current SimpleApplication instead of offering another solution, you are likely to hear about it from people other than I.
@pspeed said: Question: in what version _are_ we allowed to break stuff? Policy-wise, 3.1 may break tons of stuff that an @Deprecated tag would not fix. It's the whole point of the 3.0 to 3.1 version increase... stuff will change in non-compatible ways.Also, having an interpolate() and an interpolateLocal() side-by-side would make the problem even worse, in my opinion because now it looks like there are two of them that act like all of the other XXLocal and XX methods. If I thought people actually read the javadocs then I wouldn’t have to post links to it 10 times a week.
Stuff will break. This is just one of those things. If a third party library wants to support trunk then it will have to have two different branches. Either today or tomorrow. That’s really what we’re arguing about. You’d rather wait until some future breaking change.
This is true, however… there has to be SOME measure of consideration for those leveraging a public API. If Java took this approach, none of us would be here, because none of us would use it. right?
EDIT And no, I’d like some forewarning… the same type of forewarning given from the language the engine is written in would be an appropriate choice.
@pspeed
In most sane software companies…
Version 1.0 is release
Version 1.1 is released but is still backwards compatible with the previous version. People are given fair warning that it will likely stop supporting version 1 on the next release
Version 1.2 is release without support for version 1.
You can not tell me that this is unfamiliar to you.
Btw the whole build process is changed currently.
But I don’t get where the whole deal is with having a trunk plugin version and a stable one.
Usually I agree @Deprecated would be a solution, but in this example it is not, as having a interpolate and a interpolateLocal would imply another meaning.
Adding a additional interpolate that does work as it’s name specifies would then create the problem with silently breaking code of others.
Having a loud crash is still better than a silent decay.
Btw jme is not a company, but opensource, and if you ever followed larger opensource projects, you will see that there are very often kinda radical changes.
“I am hoping I came across pissed.” Mission Accomplished, to bad we are not a company and do not need to ensure everyone is happy to keep profit, and toxic behavior is not helping your case.
1 Like