iTwin
Evaluate native versioning scheme
Evaluate native versioning scheme (minor) compared to itwinjs-core (minor.patch), change it if appropriate to avoid potential issues with patch releases after minor version bump.
I believe we should discuss the pros and cons to having release branches using the "release/Maj.Min.x" vs "release/Maj.x". During this past release, because of the CVE's that were hit in the middle of the release, I ran into a situation where depending on how we wished to handle the situation we could only create addons for 4.1.x and 4.2.x OR 4.2.x and 4.3.x-dev. Because our current structure is only "release/Maj.x" we loose the ability to patch certain minor versions depending on the state of our native branches.
Right now, if we version bump native we can no longer create addons for the prior minor version. This can cause problems if we create the new release branch in core, but something delays the release for an undetermined amount of time, then we cannot patch any potential emergency fixes for the prior minor (which at this point in time is technically our currently supported minor)
If we don't version bump native until after the release is done, then we cannot create addons for our new dev version, and we also just have a strange workflow where creating an addon off of main branch in native creates a patch release for our release branch in core.
