The topic didn’t die, it reached a conclusion. You can see that because it is closed.
2 Likes
The whole point of a framework like this would be to not release only MAJOR releases i think. I agree that the whole thing defeats the purpose in this case.
What would happen if for example, each of the /examples was maintained by the original author, in some other repo? I think there would be a lot of stakeholders with an interest to not have breaking changes.
1 Like
Chaos, undoubtedly.
2 Likes
Mkay i think i figured out whats been bugging me the most. Maybe semver is not even the right thing, but i found an example.
This fixes a bug that seems to be introduced in the previous release. It’s not a core feature, but it might as well be as PMREM is one of the ways to light your objects. It seems like it seriously breaks a pretty big feature (viewport). The interesting bit is that it’s been fixed so soon, but still between releases.
So my first thought is, it wasn’t tested enough, the fixes could have been applied before merging, and the result could have been that this feature made it into the next version.
In order to test a PR one would have to check out the dev branch after the PR has been merged and no one is going to do that.
However, if you somehow made it available, or somehow nudged the users to test the dev branch, you’d get semver.
So, as much as you can argue that semver is happening, only that RXXX represent MAJOR versions, i can argue that semver is also happening atm, and you get minor and patch, except thay they live only on the dev branch.
The only difference i think is that it’s not sequential. If Rx1 and Rx2 represent two different MAJORS every PR merge can be either major, minor or patch. It’s the sequence of merging that makes it differ from semver.
Essentially as soon as this merges, i think it’s a PATCH. When it hits the next release cycle it’s going to be minor or major.
Thoughts?
Btw, i’ve also seen npm install 0.X.something. I could swear that i’ve seen a patch version of three.js on npm.
That’s a misinformed statement.
A lot of people tests dev. If dev breaks someone creates an issue about it within a day. It just happens that dev rarely breaks.
And in this case it broke a workflow not many people have adopted yet.
1 Like
Yes. Because sometimes something breaks at release time. Or a bug that was not caught during the dev cycle.
It has mostly been because non-breaking spaces.
Adding to that… in many cases maintainers go all the way to cloning the branch for testing purposes, even before it lands on dev. To say that no one reviews PRs or properly tests them is completely wrong and misleading.
Maintainers and the community as whole do an awesome job of reviewing PRs and making sure we are not breaking anything. Slip ups occur, which is natural thing… considering the amount of code being regularly added and the limited number of maintainers.
3 Likes
So… threejs used semver all along? I wonder why we are having this conversation 
Did I make a mistake by writing no one? I don’t want to be making wrong and misleading statements. So I’d like to change it to:
I have very little to no data available, so I am going to make an assumption. My assumption is that considerably less people, by orders of magnitude, get to use and test the dev branch, than compared to the number of people that get to use production.
All off this is easier to write as “no one”, but maybe it would benefit from being put in quotes.
To publish on NPM, it’s required to use semver.
So the three.js revision numbers have simply been shoehorned into semver format: R99 -> 0.99.0, R111 -> 0.111.0 and so on.
By the way, do people prefer r112 or R112?
I go with little “r”, tend to make the following numeral stand out a bit more. R102 r102
2 Likes
r112
This is the way
1 Like
I also prefer r112 
however, R or r is not my problem.
In examples I often look for the revision. But it is not at the beginning. 
You have to search first, and then find the following lines at revision 112:
three.js 
three.min.js 
and 
quite well hidden
three.module.js 
Oh boy, what a thread -)
Nope. I dont do it. I just dont. I migrate only if there is a feature I absolutely must use, or the bug fix that was not worked around yet. Last week I updated 111 to 112 in order to use scene.environment; the current revision is what - 115? And it does not bother me to be 3 revisions behind, like at all.
1 Like
So what do you do if some feature is broken in that particular release? To that point three is something that indeed is seldom upgraded, but this is not the case with any other package from npm for example.
What do you mean what I do? I use other release or work around it. What do you do? Sit on broken app until mr doob fixes it?
I think i do something like @looeee mentioned forge does, just sit on something like “RX” and use and hack that. But this reiterates my point of not seeing a point to new releases then.
Like i mentioned, this for example, means R113 (or something) had a feature completely broken https://github.com/mrdoob/three.js/pull/18419#issuecomment-576221992
But also maybe not, since it’s an example. But also maybe yes, because PBR is pretty core.
I went from 105 to 114 with all main projects at once, even with a lot custom core patches it wasn’t more than a hour of work.
The changes never really break something so it couldn’t be fixed within a minute, like i probably said before, to progress and improve things need to change but sometimes it might be different reasons such as contributors not being available anymore for a specific feature with no one available to maintain it.
2 Likes
Oh, i also try to make reusable solutions that can be shared with the world and could potentially work with future versions of three. For example, when i needed THREE.InstancedMesh four years ago, i did not want to do exactly this:
So instead i made a plugin and published it on npm, along with some articles detailing the inner workings of the approach: three-instanced-mesh - npm
The issues should be obvious though and i think they could be solved with semver. So, the people who did not want to wait for mr.doob to implement this feature years later could use this in 2017.
BUT, only for some arbitrary range of releases, up to some arbitrary point. As soon as some arbitrary release changed some method that this plugin used, everything broke. I think i ended up with:
if(preRandomVersion)
doPre()
else
doCurrent()
Until some other arbitrary version comes along and breaks this. Knowing that some arbitrary release is actually breaking, would mitigate this.
Also helps articles or books, ie. i don’t see
Oh this line works for webpack 1.234.576, the next one breaks at 1.234.775, and 1.235.0 invalidates all of this.
Instead
This article contains some information that applies to Webpack 2, Wepack 3 changed this and that…
Aah, now if we are in the land of libs, yes, I do see a point to this -as you cant really say “this lib works with r76 only” and expect people to be happy. But in the context of apps (or sites, what ever you call these now) you totally can - package/yarn-lock.json is now integral part of its source and it can say whatever version you want, and noone has to upgrade it just because there is new release in npm.