search

iTwin / itwinjs-core

Monorepo for iTwin.js Library
https://www.itwinjs.org
MIT License
615 stars 210 forks source link

Evaluate native versioning scheme #6129

Open ben-polinsky opened 1 year ago

ben-polinsky commented 1 year ago

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.

aruniverse commented 1 year ago

@DanRod1999 can you please elaborate

DanRod1999 commented 1 year ago

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.