-
Notifications
You must be signed in to change notification settings - Fork 18
[Discussion] Re-Numbering the plugin release so the major number matches the Angular release #57
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
This seems like a step in the right direction to me. TypeScript is a fast evolving language, and each version that will be new techniques to do things better. For Angular, I think/hope that it becomes stable, we're behind the the majority of breaking changes to fully support Ivy (Angular 13). As a side-note, we could also add a ng-upgrade schematic. This way, the upgrade path can be automated for the developer. |
One complication of this approach is how we handle the numbering when upgrading to newer versions of the ApplicationInsights Core.
And when Application Insights jumps to v3 (next major ES3 breaking change)
Or use the same Major and Minor version to that of the Angular framework and use the patch version for targeting the version of Application Insights, this is expected to cause additional issues in relation to major updates of Application Insights which could have breaking changes causing auto updates. eg Any other Suggestions? |
As we have a major release planned for early next year for Application Insights, the next release for Angular 14 support will be called v3 and we will wait until the release of ApplicationInsights v3.x (which will have planned breaking changes -- mostly around provided (backward compatible) helper functions with the removal of es3 -- But don't panic, Plugins (like this one) built for v2 will be compatible / usable with v3). We are also planning on completing the Dynamic Config update support as part of the AI v3 release -- which will likely require additional changes to this plugin. So we will wait until the major AI release before changing the renumbering strategy (eg. calling the Angular v14 release v14.x) as this could complicate things. |
This Issue will be closed in 30 days. Please remove the "Stale" label or comment to avoid closure with no action. |
Version 14.0.0 has been published and version 15.0.0 is being prepared |
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. |
Hi All,
I want to start a discussion where moving forward I'm thinking that we should change the major version number of this plugin to match the version of Angualur that is targeted (simular to the way the devkit is numbered).
Proposal
The main driver of this is that we are already drifting from the previously Application Insights <-> Angular Plugin connection and with the number of versions of breaking changed Angular versions it makes it difficult to understand what / which version should be used.
Because of the size of our team, I don't believe it will be possible to keep all Angular versions up to date with the latest Application Insights versions and while we do support backward compatibility (new versions of Application Insights will load and work with older plugins), this can and has caused TypeScript errors when also including the latest version of Application Insights in your projects during build time.
So while Application Insights v2.8.1 will load and work with any older version of the Angular 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. This does seem to depend on your tsconfig.json settings as I don't believe everyone is seeing these issues.
The text was updated successfully, but these errors were encountered: