Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[feature] support range versions #61

Open
nartc opened this issue Jul 21, 2023 · 2 comments
Open

[feature] support range versions #61

nartc opened this issue Jul 21, 2023 · 2 comments
Labels
enhancement New feature or request

Comments

@nartc
Copy link
Collaborator

nartc commented Jul 21, 2023

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:

package-a
    v3.0.0 supports Angular 16+ (signal)
    v2.0.0 supports Angular 14 -> Angular 15 (standalone)
    v1.0.0 supports Angular 9 -> Angular 13 (Ivy)
@nartc nartc added the enhancement New feature or request label Jul 21, 2023
@nartc
Copy link
Collaborator Author

nartc commented Jul 21, 2023

related to #63

@ajitzero
Copy link
Contributor

ajitzero commented Jul 21, 2023

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.

We could replace this:

[key: string]: LibraryAngularVersionSupport;

With:

// Sample type:
type VersionKey = `${number}` | `${number}-${number}` | `${number}+`

And update this to generate actual versions:

const angularVersions = data.map((x) => Object.keys(x.versionSupport));

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants