@t0neg0d said:
@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.
As jME3 is “our” product (its even in the package name) we adopted the way Apple does it with the MacOSX (and I’m sure other companies too). The first part of the version is basically static, then it goes on as you indicate, moving the whole scheme to the right.
@t0neg0d said:
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?
A language has to be the most stable thing. Which is why we still have Java 1.0 stuff we can use and why Swing doesn’t use any java.util.* packages and we still have Vector and Enumerator.
…the further you get from the core language and the more additional libraries thrown into the mix, the less stable a system is. Given all of that, the fact that 3.1 is still as compatible to 3.0 as it is, is quite remarkable considering none of us earns a dime for working on it.
We are in a tighter place still because small changes to architecture or otherwise can have far-reaching implications to an end-user. We either change nothing and stagnate or we create branches and points where we can break things. 3.1 is one such point. You can choose to support both branches or not as you see fit.
@t0neg0d said:
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.
Oh wow, just saw this…
Well… think about why I am the only core member you can blame for so many things at once ^^ So when I say that I don’t have much time for the engine… I guess such things might happen. And I have to agree to what Empire said about toxic behavior. You seem to fight against some imaginary “jME Authority” or something. In fact you just repeatedly bang on the heads of a literal handful of people and you could actually hurt the whole project more than you intend to help it (if I may interpret your behavior in the best sense).
@t0neg0d said:
@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.
I’ve been doing software development professionally for over 20 years now. I’ve worked at many different companies during that time. I was even a contractor for about 5 years and worked with several companies in that time in many-month stints. At my current company I was even twice responsible for creating our standardized version scheme in different environments as part of Q/A planning.
Not one single time have I ever encountered the version scheme you cite. A know some open source projects adopted the odd branch = stable, even branch = unstable but I’ve never heard of anything like what you outline.
Almost universally the most common approaches are variations on:
x.y.z
x = major product change. Generally the architecture, everything, is completely incompatible.
y = new features, changes may be incompatible… it really depends on the policy. Ours is that y can introduce breaking changes.
z = bug fix release. All attempts are made to maintain full backwards compatibility except when that backwards compatibility is a major bug. Some bugs may even be left in if they change the behavior of the app in a significant way and otherwise have simple work arounds.
@pspeed said:
Almost universally the most common approaches are variations on:
x.y.z
x = major product change. Generally the architecture, everything, is completely incompatible.
y = new features, changes may be incompatible... it really depends on the policy. Ours is that y can introduce breaking changes.
z = bug fix release. All attempts are made to maintain full backwards compatibility except when that backwards compatibility is a major bug. Some bugs may even be left in if they change the behavior of the app in a significant way and otherwise have simple work arounds.
Y pretty much sums up what I just said. However, you stating that all the companies you’ve worked for over the past 20 years, leads me to believe that 80% are not much more than startups. And the other 20% you had nothing to do with Quality Control.
EDIT: I’ll state this again, in a single sentence: If you can not keep compatibility issues under control for a minor version release, you might want to consider getting a person involved to ensure that you are able to do this.
It’s not the end of the world to admit that you could use the help… you have enough shit to deal with as is.
@t0neg0d said:
Y pretty much sums up what I just said. However, you stating that all the companies you've worked for over the past 20 years, leads me to believe that 80% are not much more than startups. And the other 20% you had nothing to do with Quality Control.
EDIT: I’ll state this again, in a single sentence: If you can not keep compatibility issues under control for a minor version release, you might want to consider getting a person involved to ensure that you are able to do this.
It’s not the end of the world to admit that you could use the help… you have enough shit to deal with as is.
I state this again: 3.1 is not a minor release. Its as major as jME3 can get (package name HELLOOOOO?)
I hesitate to mention this, but if Vector3f.interpolate() gets renamed between 3.0 and 3.1, shouldn’t ColorRGBA.interpolate() also get renamed? Same issue, it seems to me…
@sgold said:
I hesitate to mention this, but if Vector3f.interpolate() gets renamed between 3.0 and 3.1, shouldn't ColorRGBA.interpolate() also get renamed? Same issue, it seems to me...
Yes, it was one I missed and now I have to commit it to two different places so I’ve been lazy.
Tonegod, you are a talented member of the community and your contributions are always well received, but let’s get back to the real world. Nobody is perfect, and nobody is claiming to be, yet your attitude always seems to question exactly that, and if we take a look at your history on here, if I felt like it I could argue that you spend more time creating new ideas and increasingly less time actually finishing them. But you know, if being the lead of several highly profitable projects has taught me that the way to get the most out of people is by remaining level headed, constructive and positive throughout. You can’t just attack people like that and expect any kind of positive result. At best you’ll get the finger. The devs are devs because they are justifiably so. A little respect wouldn’t go amiss. We all lose our temper. Especially when we have invested so much time and effort in something just like you have, but my experience as both a team leader and a father tells me to walk away until I’m in a better mood, and come back when I’m in a more constructive, as opposed to destructive, state of mind.
perhaps some of this could be aleviated when/if jmonkey moves to git ^.^ then there could simply just be a “broken vector3f branch” and stuff like that.
