Maybe it’s not a good example then what about things like angular or react?
Angular is run by a team at Google, and React is run by a team at Facebook. three.js does not have that level of funding and organisational structure and I don’t see any point to comparing these.
This has been discussed on Github many times, but this is the main thread:
I think the biggest takeaway from this discussion is that, as long as you use three.js from NPM then you are already getting semver - 0.95.0, 0.96.0, 0.97.0 etc.
The argument against semver on the repo side is that once you do that, people expect patches against old versions - so they will demand 0.112.1, 0.112.2 even when we have progressed to 0.115.0.
That adds extra strain to development, which I don’t think anyone is will to take on. And if we don’t agree to release patches to old versions then there is zero benefit to adopting semver beyond “following the crowd”.
Is there a predetermined pace at which the minor-changes and major-changes releases come out ?
That’s the point of Semver, you can speak about patch-changes releases and API-changes releases separately, “enact” that breaking changes will not occur too often, but continue releasing bug fixes at fast pace. As for users expecting that bug fixes will be released for old versions, they can kindly be explained that they should do it themselves IMO… It’s purely a communication matter, the current system does not help them more.
If i understand the issue correctly, this would imply that there were never any breaking changes, so there’d be some numbers in MAJOR as well
. Sure these two projects do, but let’s say that 0.1% of all the npm packages are maintained by no more than four people, that’s still 350 examples to prove that semver can be used by a small team, or even a single developer. I try to look at it generalized, it doesn’t matter who develops it or how many people consume it, you have a developer on one side, and a user on the other.
Would you entertain the possibility that people sometimes enjoy discussion for the sake of discussion? I find this phenomenon fascinating and if there were interested parties I could spend a lot more time discussing it.
It doesn’t have to convince YOU (the core) of anything.
Ie. no change has to appear out of this discussion. AFAIC this discussion can go on for ever with everyone giving their two cents, maybe 3 years down the line the right person will come with the right argument and make us all think. If not, it serves a historic purpose, like now i undersand that the reason behind the R thing and monthly versions a bit better.
For example, these two approaches, both coming from core members, seem to be the polar opposites Autodesk Forge example was described as something where you never update three at all. But then there is this inherent guarantee that there will be a release every month no matter what.
I’m not calling this out as wrong, please don’t get me wrong. It’s another thing that i find fascinating about all this, and i start from assuming that i missed something and don’t understand the issue completely.
Right now, how i understand this is that you should stick to whatever three.js version was the latest at the time you decided to start using/learn three.js, and from there on be at ease because you are aware that you could upgrade three every month if you wanted to… but don’t do it
I think my key stumbling point is this example. Why is 115 even in the works, if 112 has bugs and people want them fixed. I think in the current state of the world, 115 is 112.67 but with some new stuff that can potentially break (new bugs) and so this cycle keeps repeating. It feels like the only missing thing is designating what should be in 115 (new awesome feature) and what is missing from 112.0 (existing stuff is broken).
I don’t know though what happens with PRs that are constantly being made. One may not be aware of whats the plan for 115 and what are the bugs for 112, but this can also be solved with road maps and ticket triage and stuff?
Who do you think is providing the pressure? Anecdotal evidence here shows that an entity such as Autodesk forked three years ago, and never bothered to check back in on the 40 releases that happened afterwards.
Is there possibly a “other engines have it” guideline that is being subconsciously applied here? I think some of the features made it in because “unity can do it”, “in unreal they have X” etc. Like why is 115 being made if there is no plan for it?
I think There’s no plan for 115 is not a true statement, there are some plans, at least that it should come out next month if nothing else. The roadmap can also possibly apply here, you know for sure that there will be 12 releases a year, you just don’t know what is going to be in them.
@mrdoob btw i want to acknowledge that what you’re doing is amazing. I haven’t been in your shoes and i can only imagine how complex of a task you’re dealing with. My humble 2 cents, that you don’t have to accept in any shape form or fashion is that there could be frameworks and approaches out there that could make your life easier. Maybe this is the best way, maybe not, the two cents are just to be more open to those ideas
A couple of examples that pop to mind: modules and typescript support, weren’t available when they already sort of became a standard in the JS world, now i bet a lot of people can’t live without them. I’m kinda thinking that might happen here too. Maybe not in the form of semver, but at least something that represents a “stable” version of three.
The purpose of this forum is to provide a space to discuss things that don’t fit on GitHub, such as help requests, showcasing projects, jobs requests and so on. On the other hand, discussions about changing the library to semver or other suggestions about the development of three.js are more suited to Github.
While we’re happy for the tone of conversations here to be a bit less formal than GitHub, that doesn’t mean it should be directionless. We are here for the purpose of solving problems, learning and sharing knowledge, getting feedback on things we have built and so on. Anything else is noise and should be kept to a minimum.
If you want to shoot the breeze, chew the fat, blow off steam, gossip, complain or otherwise aimlessly spill words into the ether, better to do that on reddit or down the pub.
My personal experience with semver is that it just doesn’t work on larger API such as threejs. Almost every change ends up being breaking, so if you’re honest in your versioning - most of the releases end up being MAJOR. From that point, I find sequential single number kind of refreshing.
Having worked in the lead role on software projects, I also feel that a lot of people just don’t get that “consideration” of an idea is a lot of work. “Why not X, tell me?” - well, you think you have considered every detail - but you probably didn’t consider even a half of what’s important to the project. Also, if X fails it’s not your responsibility, it’s someone else’s, namely the guy who was naive enough to listen to you that ends up with the mess.
Let’s say you have two ways of doing a thing: X and Y, say you’re currently doing X, but Y is 10% better somehow. Well, switching to Y has a cost, and that cost may or may not kill the project, but it is sure to create chaos. Some people might even, God forbid, pen an article titled “I wonder how many trees get burnt down and kids get neglected from process churn”.
Like everything, there’s a set of advantages to experimentation and change, but there are clear disadvantages too.
@mrdoob pointed out a couple of times here alone that this process is comfortable for him compared to some of the offered alternatives, why do so few people consider that as an optimisation criterion?
I love you all guys, no offense meant. Just shooting my own breeze here, enjoy coolness of it