Ensure support for each Angular version

[Dumluregn]

Are you reporting a feature request or a bug?

Task

Details

Analogous to ckeditor/ckeditor4-react#121 - it would be good to have at least unit tests for each Angular version we support (so starting with Angular 5).

A step further would be having a separate build for each NG version, as there are both minor and major issues in both Angular and Typescript backwards compatibility (see #78 or #138) and though it may currently still be possible to adjust the custom project to run CKEditor 4 component no matter which NG and TS versions are used, in the bigger project where there are more dependencies it may turn out it is impossible to find the setup which will work.

Aaaand the clearest (but in the same time also most confusing 😄 ) way would be releasing the major ckeditor4-angular package version each time when a new Angular version comes out (so twice a year) and give it a number corresponding with the Angular version it is dedicated for (so e.g. for the current version - ckeditor4-angular 10.0.0). There is a number of things to figure out in such approach, like:

• should we release the package version for each NG version to catch up or just start the convention now?
• what to do about the gap between current version 2.0.0 and the next (so either 5.0.0 or even 10.0.0)?
• should we develop only the most recent version (so the users of older Angulars can feel abandoned) or each existing version (right now it would already mean maintaining 6 different versions 😱 )?

Taking into account the number of potential issues with the second and third approach, we should probably start with just having the samples and unit tests for each NG version and see how broken (or perhaps working) it all is. When doing this it would be nice to take notes if any adjustments in building process are necessary and add it to the docs or README file.

[f1ames]

Taking into account the number of potential issues with the second and third approach, we should probably start with just having the samples and unit tests for each NG version and see how broken (or perhaps working) it all is.

Side note: More a technical thing but it could be useful to utilize GH Actions here. We can have workflow which runs same/similar tests with build package for each Angular version using separate env for each version (so we don't need cleanup logic/magic, reinstalling stuff, etc). This can be achieved using matrix strategy so each version would be tested on a separate OS image.

[Dumluregn]

As mentioned in ckeditor/ckeditor4-vue#6 (comment), there is quite an interesting convention in CKEditor 5 Vue integration:
ckeditor5-vue - for latest Vue (3)
ckeditor5-vue2 - for Vue 2

Following this convention in our Angular integration we would now have:
ckeditor4-angular - for latest Angular (11)
ckeditor4-angular5 - for Angular 5
ckeditor4-angular6 - for Angular 6
...
ckeditor4-angular10 - for Angular 10.
After the release of Angular 12, ckeditor4-angular code becomes the ckeditor4-angular11 package, while ckeditor4-angular is adjusted to Angular 12.

Pros:

• we don't have to worry about the Angular backward compatibility as we basically freeze the older packages in the state where we know they work
• we can still bump CKEditor4 versions in all repos relatively easy

Cons:

• new features for integration would probably be developed only for latest Angular version
• releasing 5+ packages instead of 1 each time CKEditor 4 is released
• it's quite possible that some of the repos turns out to be identical if there are no breaking changes in Angular features we use

Summing up, this approach seems like an overkill here - it would be useful if a) adjusting integration to each Angular version was very troubling or impossible (for now it isn't) or b) the Angular major releases took place once in 2-3 years, not every 6 months (the number of repos to maintain would currently grow to quickly).

For now we should rather aim at customising build process within the current repo (when it's necessary). Still, the very approach is quite interesting and we may want to use it somewhere sometime.

[f1ames]

There is already a PR in progress covering that issue, see #202.