Angular 13 Support (libs update) and version policy about angular

[christopherthielen]

Hey folks, great discussion and thanks for contributing! I'm open to switching ui-router to the proposed version scheme.

Background:

UI-Router for Angular has always supported the latest version of Angular, plus one previous version, i.e., we now support ng13 [latest] and ng12 [latest - 1] in ui-router/angular version 9.x. IIRC this mimicked the ng support scheme offered by other libraries at the time. UI-Router has always been built using the previous version of angular (latest - 1) which I believe was intended to provide compatibility with both [latest] and [latest - 1]. However, as I think about it now it doesn't really buy the end user any extra flexibility because it only allows them to upgrade ui-router while remaining on an older version of Angular. More likely they're driving this process from the other direction (upgrading to the latest Angular on a 6 month cycle).

Going forward:

I think going forward, we can drop the 2 version support, and simply target the latest Angular version. I'm also OK with synchronizing the library major version number with the angular version it supports (although I am wary of this on principle because it means the library stops being semver and complicates breaking changes in @uirouter/core for example).

We will still have the problem of updating the sample apps and angular-hybrid but that process may be made simpler by supporting only a single angular version. (for details on the nasty process of bumping versions, read the notes I took about a year ago when upgrading to ng11). This entire version bumping process would be much simpler in a monorepo. Being able to bump all the versions in a single PR and then publish packages after the fact would be 💯 .

[mokipedia]

As the Monorepo is quite some work which need further planning before jumping in, I started an issue with general informations and current ideas / decisions flying around in other issues.

[mokipedia]

I second this proposition to drop older versions and make a new major version whenever the supported angular major version changes. I also find the proposed synced version number intuitive and declarative.

However, going this direction means an overhead as you need to follow angular ~ every 6 months and as history has shown, most projects are not that active - ui-router included. I think this would be nice to have, as long as there are active maintainers for the project (not necessarily actively developed, but maintained).

[thekip]

Sounds reasonable.
Hopefully bumping version of the project is not a very big task as long it's straightforward and not including extending test suite to test again all obsolete version.
So i think community could help with that. So the project wouldn't be abandoned as long as there are projects using it (at least we use it in our app and it's quite hard for now and in closest future to migrate to something else)

[mokipedia]

It would probably also mean, that angular-hybrid, angular, the sample apps and maybe others i forgot to mention would be moving along with the version bumps while core, angularjs and react stay at the current scheme.

[s001dxp]

I've been using ui-router for about 6 years with first angular 1 then with angular 2. I maintain a very large application and sometimes get a few angular versions behind before I have time to upgrade. Having synchronized versioning would be a a great help--I'd no longer have to do the research to find which ui-router version is compatible. So, I put my hand up for this.

[jpike88]

It makes sense to just target the latest version now, there's not exactly any groundbreaking features to worry about anymore so people won't be too upset about it.

[wawyed]

I think it's okay to make @uirouter/angular follow angular version but the fact that relies on other libraries such as @uirouter/core and @uirouter/rx would mean that any breaking change would need to align with angular upgrade version which makes me a little bit vary of doing so.

[mokipedia]

@wawyed not sure I understood you correctly.
Do you mean that by aligning to angular versions, you can only make breaking changes when angular is updated to another version?
Or do you mean, that if @uirouter/.. has a breaking change, you would also need to update angular to the latest version in order to get the change?

[wawyed]

Do you mean that by aligning to angular versions, you can only make breaking changes when angular is updated to another version?

This, yes.

[mokipedia]

Ah, yes.
I've seen some sort oft "soft alignment" (not sure what to call it), it is quite common.

• Project has its own Version number, not e.G. 13, same as Angular 13 (current).
• Project updates to new Major when Angular Major updates
• Project updates to new Major when breaking change, regardless of Angular Major update

It still is aligned somewhat with Angular, as 1 major version only targets 1 Angular major version, but you are free to make necessary breaking changes if needed. However you would need a sort of table in the docs to map which ui-router version is targeting which angular version.

Would that be a better strategy in your opinion?

[jpike88]

Processing legacy "View Engine" libraries:
- @uirouter/core [module/esm5] (https://github.com/ui-router/core.git)

@wawyed this warning would show indefinitely if /core isn't updated to conform though..

[stale]

This issue has been automatically marked as stale because it has not had
recent activity. It will be closed if no further activity occurs.

This does not mean that the issue is invalid. Valid issues
may be reopened.

Thank you for your contributions.