This:
should just become, an inherent historic part of threejs.
Could be under
threejs.org/v/152
And could even formally declare, all name changes.
So if anybody anywhere, want’s to make a script or whatever to automate the process, they could do so. And share it with the world.
In case any readers are not aware, we do maintain a migration guide for each version:
Unfortunately – automating upgrades with each version is not likely to be an easy task. I don’t think maintainers are able to make such a time commitment, which would come at the cost of library development.
I don’t work on the library.
But I might make a script to update Threejs programs automatically.
Reminds me of the quote:
“Given enough eyeballs, all bugs are shallow”
Linus Torvalds
Within that link you posted, under header:
151 → 152.
There should be a link to the article I posted.
And within that article there should be a link back to the Migration guide.
Could even be formalized somehow so there’s the formal, cryptic, new version explanation.
And the more human one.
And maybe, if the formal one, could also take form of just a json file.
Somebody could just, have a script that automatically downloads the latest changes.
And automatically creates a script that implements those new rules upons files.
Maybe… this way, new Threejs versioning, could become a non-issue for those who have Threejs programs.
Could even have a scroll bar. And it would just, cycle your entire Directory of Threejs programs, back and forth through the versions. Bit of an overkill, I know. But kinda funny.
Agreed that links back and forth would be worthwhile!
The harder part is that it isn’t easy to write a script with enough context to do these migrations correctly. I’ve migrated 100+ examples in the three.js codebase, and there’s a certain amount of context required. Renaming a property is easy. But knowing how a texture is being used, and what kind of data it contains, determines what color space it should be given. If your textures were not already tagged with color space information — as many were not — then a script has no practical way to infer that. The color space data contained in PNG and JPEG files is very unreliable.
Yes I’m sure there are many pitfalls there, that can complicate things.
When I think about it, a version upgrade. Is actually made up of units.
And those units are what they are listing there in the migration guide.
We could name the units, a,b,c… etc.
So they would become, 151a, 151b, 151c etc.
And those units, they can be of a type.
And some types, are easy to automate.
And some… not so much.
And a script could maybe implement some of them.
A script could have fully mastered this type, or that type… of updation.
And the script would list, the parts it can do, and the parts it (still), can’t do.
And who knows, maybe one day we find a way to implement version update, type x.
Solving that problem forever. Bringing us one step closer to the scroll bar of versions… dream.
It’s kinda like starting a journey.
ThreeGPT will do it in the blink of an eye.
