Possibly connected - #176.
This task wasn't as simple as I thought as updating internal dependencies has an impact on the release process. In short: the ng-builder package that we use to create Angular-compatible NPM packages uses Angular's deps to create these NPM builds and we need to keep it at a low version to serve a package that is compatible with Angular5+ apps :sob:聽
On the other hand, it makes the package look old and unmaintained on 聽https://www.npmjs.com/package/@ckeditor/ckeditor5-angular. IDK what we should do here to fix that situation. At some point, we should migrate our old custom library-creating tool to the official one - https://angular.io/guide/creating-libraries. The problem is that the official one will be working only for Angular 8+ or Angular 9+ apps. This could be done as a major release to not break backward compatibility, so we could still support the 1.x version and porting some important bug fixes there. Though, then we'd be in the trouble maintaining two versions of that lib.聽
cc @wwalc @mlewand
https://angular.io/guide/releases#support-policy-and-schedule

This could be done as a major release to not break backward compatibility
I don't feel competent enough here to decide what direction to take, but I think I'd be okay with doing whatever is right to support just versions 8+ starting from April 18, 2020.聽
If it turns out that there is a significant demand for supporting the latest CKE5 on older versions of Angular, then we always will have an option to have a new minor release for the 1.x product line.
There would be of course some side effects, like having to keep the public documentation for both integrations for some time etc.
A part of this task - #96.
There's a high chance that the old Angular library compiler leads to:
As I see - https://github.com/nicky-lenaers/ngx-scroll-to#installation - it's normal to have a few branches and releases for various Angular versions, though it would be painful to maintain it :/
As I see - https://github.com/nicky-lenaers/ngx-scroll-to#installation - it's normal to have a few branches and releases for various Angular versions, though it would be painful to maintain it :/
Are you sure? Isn't that readme just pointing to older versions of the library that have been released years ago?
Hm, right, readme is pointing to older versions, though we could have a temp branch for old versions for hot fixes.
Hi, Is it fixed?
I do not see a reason why would a library author care about an unsupported Angular version. Angular apps should be always updated to the latest Angular version.
The library should be working with Angular 9+ (v8 will be unsupported after a month now).
My suggestion is to create a new major v2, and leave the v1 as is, but nobody will care about v1 support anyway.
You can also create v3 in case there would be some features which are compatible with Angular 10 only. You might "name" your versions v9 and v10, to be easily recognizable which Angular version is supported. This is a quite common practice with Angular libraries.
Development focus should be always on the latest version of the library.
Most helpful comment
https://angular.io/guide/releases#support-policy-and-schedule
I don't feel competent enough here to decide what direction to take, but I think I'd be okay with doing whatever is right to support just versions 8+ starting from April 18, 2020.聽
If it turns out that there is a significant demand for supporting the latest CKE5 on older versions of Angular, then we always will have an option to have a new minor release for the 1.x product line.
There would be of course some side effects, like having to keep the public documentation for both integrations for some time etc.