[Discussion] Re-Numbering / handling framework version changes so the major number matches the React / React-Native releases

[MSNev]

Hi All,

I want to start a discussion were moving forward I'm thinking that we should change at least the major version number of these plugins to match the major version of React / React-Native framework that is targeted at, this may also mean moving out the react plugins in the same way we did for the Angular plugin.

I have basically this same discussion happening in that repo as well microsoft/applicationinsights-angularplugin-js#57

Because of the size of our team, we don't have the capacity or the active working knowledge to keep all of the React / React-Native versions up to date with the current framework releases with the latest Application Insights version. And internally, we are generally not supporting updated frameworks until it has been released for at least 6 months to give it time to settle down (not withstanding / considering any beta releases it may have had for this timeframe)

This comes particularly to a head when the version of the frameworks update in a non-backward compatible manner. As the current React 18 update appears to be causing...

The basic thoughts on the approach will be to use branches to keep the difference between any release isolated so that we could apply any required security patches (if necessary), however, as a mono-repo using branches for different components becomes problematic as keeping the "Core" portion of those branches would just be practically possible. So this then means any older framework versions would become frozen to the version of Application Insights at the point of branching.

Branching Options

• Keep in mono-repo and freeze older framework versions to older Application Insights (No chance new feature implementation, or new config support (for typing)) -- will have potential issues with multiple SDK "instances" being resolved for npm packages
• Move out to new repo and target AI version "ranges" (like we have done for the Angular Plugin), so we will only need to "publish" an updated version of the React / React-Native plugins when TypeScript typing changes or new features are required and also potentially decoupled from AI releases.

For either of these

The master/main branch will target the minimum supported release to the "current" version, (note singular for mono repo -- no ranges)
And when we change the targeted verson (in master) of React / React-Native we then

• Update the major version # and reset to 0.0 (so 14.0.0)
• Create a branch for the previous version (for hotfixes) and active development will generally pause except for security related issues

The main driver of this is that we are already drifting from the previously Application Insights <-> React/Native Plugins connection and with the number of versions of breaking changed Angular versions it makes it difficult to understand what / which version should be used. And it less of a cognitive matching or requiring to always lookup some compatibility table.

So while Application Insights v2.8.1 will load and work with any older version of the React Plugin (when just injected via the "extensions" config, TypeScript is unhappy with the flexible signature changes that we have introduced to support older and new extension / features, if you try and "compile" within the same project. This does seem to depend on your tsconfig.json settings as I don't believe everyone is seeing these issues.

Numbering Options

So then the question is about numbering and targeting the framework versions, do we just target link the major number or the major and minor numbers

So do we number as

<major framework#>.<minor framework #>.

• this WILL cause potential breaking changes leaking on updates for Application Insights, but not for the framework.

<major framework #>.<major Application Insights #>.

• while this will avoid major breaking changes for Application Insights but will cause Typing signature compiling issues and not for the frameworks.

Examples

Using Targeting Application Insights major as minor (eg 2.8.1) with any version of react 18.x.x

• 18.2.8 (this could have TypeScript typing issue for cases where patch releases update the signatures (in a backward compatible way -- using a union type from AI perspective), but this causes an issue in that what version number do we use to represent an updated "patch" release to "fix" the typing issue?
• 18.2.0801 (We could do something like this? But it assumes we will never end up with a minor / patch number > 99)
  And when Application Insights jumps to v3 (next major ES3 breaking change) it jumps to
  -18.3.0000

Or using framework Major and minor)
React 18.0.x - 18.0.020801 (for React 18.0.x with Application Insights 2.8.1)
React 18.1.x - 18.1.020802 (for React 18.1.x with Application Insights 2.8.2)
React 18.2.x - 18.2.030000 (for React 18.2.x with Application Insights 3.0.0) <- This WILL likely have breaking changes from Application etc

Any other Suggestions?

Part of this is to also allow numbering "space" for releasing patches if required that would at least follow semver (mostly)

[kirkone]

Move out to new repo and target AI version "ranges" (like we have done for the Angular Plugin), so we will only need to "publish" an updated version of the React / React-Native plugins when TypeScript typing changes or new features are required and also potentially decoupled from AI releases.

I would support this approach, because it seems to work for the angular one.

Is there a way to help?

[MSNev]

@kirkone - Not at this point in time. But if/when we create the separate repos (which I think is likely) assistance will be more than welcome.

[4-1-8]

It's a complicate situation where it's difficult to have both world. Basically, the package is in the middle of a relation between IA and React. It should have it own independent numbering, but that would be even more confusing.

I would try to guess that more people are interested in developing React application and use AI than people would like to use AI and maybe use React. So I'd be more in favor of matching React numbering (for major).

Edit: Separating concerns (IA and React) in two libraries was a nice move!

But of course, the dilemma is how to then also keep track of AI and update it for multiple versions?

Anyway, I just saw light and I'm waiting for React 18 compatibility 😅

Good luck!

[MSNev]

FYI - I've started the process of moving the react-js and react-native extensions to their own repo's.

So the next releases will be from those repos. For the initial releases they will most likely just unpin from the single specific versions of Application Insights SDK to allow upgrades.

Once these initial "unpinning" releases are done we can then look at re-versioning based on the major framework version.

As react-native is still 0.x.x we will probably keep its existing versioning until it goes prime time.

[MSNev]

FYI - New repo's are now live and we are planning to perform an initial release from them tomorrow with the only difference will be that they will unpin from v2.8.5 of AI. And we will also validate the release pipeline for these new repo's.

[4-1-8]

If you need testers with the new solution, we'd be happy to help and provide feedback.

[MSNev]

v3.3.6 (React 17) release from the new repo is successfully published.

I will probably be a few weeks before we can get some time to create a new React 18 release, unless someone wants to contribute by creating a PR to speed up the process 😸

[4-1-8]

Great job! It will make those libraries more maintainable.

[MSNev]

Closing now that the react-js and react-native are in their own repo.
Plan is to wait until the next major release of the AI Sdk and then we will use start using the major number to match the framework (so React will become 18.x.x) react native will continue the current numbering (because it's 0.69.x)

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.