You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, we only support lib version <-> angular version as a 1-1 relationship. In reality, many packages support multiple Angular versions while staying on the same major version. We should come up with a way to support range version. For example:
If we don't want to modify the existing structures too much, we could set the key as "16+" or "14-15" and deduce the number range accordingly. The function for generating allAvailableVersions can be updated accordingly.
A limitation of this approach is how to handle "16+" since we need to know the current latest version. We could hard-code the latest version in some exported constant, and we need to maintain it for every new angular release, or we could try to get the latest number via GitHub API.
The API way has an issue that we can only fetch the latest releases in order, but that could be a back-ported patch release to an older version. We would need to take all release names, trim them to version numbers, and pick the largest value. Hard-coding data will be much simpler since, as it stands, there is a lot of manual work in maintaining the data for this repo.
Another limitation with supporting "16+" is that when a new version, say 17, comes up, the libraries may not actually support v17, but 16+ implies it supports something which didn't exist at the time of writing.
We can avoid both of these options by not supporting "15+" and this should be written as "15-16", and "16+" should be written as "16".
Currently, we only support
lib version <-> angular version
as a 1-1 relationship. In reality, many packages support multiple Angular versions while staying on the same major version. We should come up with a way to support range version. For example:The text was updated successfully, but these errors were encountered: