Pros and cons of three's versioning system

What is three’s versioning system called, and how does it differ from semantic versioning?

What is the expectation when it comes to which version should be used? I think i’ve seen some common examples and additions require three to be fairly recent, but then I’m also under the impression that breaking changes may appear in any given version.

I’ve had some things warn me about deprecation, how long can i expect these to warn me before just failing?

1 Like

I’m not sure what the name of the three.js versioning system is. A revision system perhaps? It’s a similar to Ubuntu’s system, and is better suited than semver when software has a fixed/agile release schedule. We release a new revision roughly every month. Ubuntu does it every six months I believe.

Use the latest version for a new project. For older projects, stick with the version you used to build it, or update using the migration guide. If you do this every couple of months, it’s usually very easy to update. If you are updating 20 revisions in one go, it’s going to be more work.

For larger projects, or if you need to heavily customise three.js, it might make more sense to start with the latest version and then stick with that for the life-cycle of the project. For example, I’ve been working a lot with Autodesk Forge lately. Even though they regularly update the forge software and release new versions, they still rely on three.js R71.

Several years at least. I’m not aware of any deprecation warnings that have ever been removed. But maybe some of the really old stuff has been taken out.

5 Likes