Code changes, version numbers get bumped. But what does it mean, anyway? Starting with Kiri 2.0, you could reasonably read it as:
- first digit is generation (usually UI design workflow)
- second digit is related functional improvements
- third digit is related to bug fixes
There has been significant UI rework between 2.x, 3.x, and 4.x. The largest mid-cycle UI update was the introduction of CAM operations in 3.5. What I have not been totally consistent about is how to handle beta / bleeding edge code.
With 3.0 we had the first reliable way to select between one of the last 5-10 release. And usually there was a beta option. With 4.x I changed this and dropped the “beta” instead choosing to make the latest branch available, but not served by default. So the casual user would not know about more recent branches, but if you went to the version chooser, you might have something new (and perhaps a little less reliable) to play with.
Why bother to rehash this? Well, with 4.2 and 4.3 a lot of stuff is changing under the hood for which there should be no apparent UI changes. 4.2 had a relatively major change to CAM pathing which introduced the production of arc code. This is still marked as beta and not served by default. But that will change this coming weekend.
4.3 will see a completely seismic change in the underlying code. We’re moving from a legacy bespoke module system to modern ESM. This should make the project much more approachable and attractive to new developers. It is also an opportunity to rework and fix up a ton of poorly maintained sub-systems like the standalone “engine” and the “frame” api.
I struggled with whether to bump the first digit or skip a few second digits to mark the significance of this update. But it’s something which, when done properly, will go completely unnoticed by users. Hopefully you will not! But if there are corner cases we missed, please be patient. The fix will be fast and painless.
4.3 will move to production by the end of July.