Angular 13 Support (libs update) and version policy

[timofei-iatsenko]

Looks like it's become more and more confusing and hard to maintain version of angular bindings which would works with different versions of angular.

I did a quick investigation of big angular projects (rxjs, primeng) they all use "aligned" version policy. Means every version of library is aligned of one specific version of angular. It might be explicitly stated in library version number or library might use own versions, but the fact is they all support only one angular version in time (even if it could potentially work with higher version).

I started working on support of angular 13 for this project and found some difficulties in current library policy. I see tests for angular 10 and angular 11, and tests for typescript version prior version 4.

The fact is that if i build package with latests angular compiler it would be compatible only with angular 13 (and 12, but angular team don't recommend it).

Means i should drop all tests for older version of Angular and outdated Typescript versions (current supported range is >=4.4.2 <4.5).

So my question and proposition may be switch ui-router/angular to the same policy? one lib version => one angular version. For the simplicity we also could follow angular versions. Means next version of the library would be 13 instead of 9.

I don't have much experience in maintaining open source projects and bringing "satisfying" backward compatibility, so feedback from maintainers and community is much appreciated.

[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).

[timofei-iatsenko]

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.

[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.

[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[bot]]

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.