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.
Honestly guys, I don’t think there’s any point continuing the discussion of semver here. It’s just wasted effort since this was already discussed and decided on Github.
No technical reasons. Just trying to make things easier for us humans
Personal sanity
Before adopting monthly cycles, release cycles could go on for up to 6 months. Writing the change log was insane and it always made we want to quit the project.
Predictability and honesty
Developers know that next month there will be a new release. If something broke, unless it’s very urgent, next month it will be fixed.
Letting users shape the API
The faster you can get new features out the sooner you’ll get user feedback (or PRs) and the faster you’ll be able to iterate and improve the design of the API.
[I’ll add more here if I can think of more reasons]
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
Maybe, just maybe, people should do whatever they are comfortable with, and own up to their actions without having to blame other people for the problems that may arise as consequence of that.
I, also, would like to think that everyone lives happily ever after, the end.
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?
There’s no plan for 115. And there is no roadmap. If there was a roadmap we would feel pressure to follow it so we meet user expectations and we would have to apologize if we don’t follow it.
It’s been a few years running the project in our own way and seems to be working.
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.
In my experience, online forums tend to be used with the hope of solving issues not just for the sake of discussion. The later seems to be more appropriate in bar, pubs, meetups, etc
Don’t be disappointed if people here don’t engage in discussions that don’t seem to go anywhere.
I always thought that this was a more informal platform but that could be the early 2000s way of thinking, today thats probably reddit. SO though is another league.
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.
Why is it aimless though? Collaboration - i’ve seen people get organized here to work together on stuff. Maybe enough people see this and band together to work on something.
Also feedback. I see this as a problem:
It could be an ongoing (but yes also centralized discussion), but it seems the github topic died?
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
what about things like angular or react?
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.
