fix: supporting future unstable versions

[satanTime]

Summary

Allows to work with alpha, beta, rc etc.

Test plan

CI/CD doesn't fail, no regressions

Does this PR introduce a breaking change?

• Yes
• No

Other information

The plan is to avoid errors like:

npm WARN Found: @angular/compiler-cli@14.0.0-next.15
npm WARN Could not resolve dependency:
npm WARN peer @angular/compiler-cli@">=10.0.0" from jest-preset-angular@11.1.2

[ahnpnl]

I don’t think it’s a good idea to do this. To test alpha beta thing, we would need to release on next tag. Our goal is only aiming to support stable version for latest tag.

[ahnpnl]

Probably this should be merged into next branch which I need to create one. So we can always release on next tag for experimental unstable things.

EDIT I already created next branch. You should adjust your PR to merge target to it.

[satanTime]

What is the difference between supporting the next or stable version of a future release which hasn't been tested at all?

if a library fails with 14.0.0-next.x it will fail with 14.0.0 too.

[ahnpnl]

Our policy has been always targeting stable version of Jest + Angular. We would like to keep that always.

In the case of supporting unstable version, it should be considered under next tag only. next tag gives people a chance to test out unstable version while latest tag is for stable stuffs.

[satanTime]

Isn't that odd? You target to support stable versions which wasn't actually tested for compatibility.

I think, what you describe requires to add a version boundary, like >=11 <12, so anyone would know that stable 12 hasn't been tested yet and might bring unexpected failures and side effects.

[wtho]

@satanTime it's just more work for us to support next or release candidates as well and we always decided against it.

if a library fails with 14.0.0-next.x it will fail with 14.0.0 too.

That might not be true. There could be a small change between 14.0.0-next.x and 14.0.0 which makes it easier for us. Note that we partially rely on internal angular APIs.

[ahnpnl]

Isn't that odd? You target to support stable versions which wasn't actually tested for compatibility.

I think, what you describe requires to add a version boundary, like >=11 <12, so anyone would know that stable 12 hasn't been tested yet and might bring unexpected failures and side effects.

I agree with setting supported version range. It's a good thing to do, like now it would be >=11 <14

[satanTime]

That also sounds good to me. Should I update the PR to add <14?

[ahnpnl]

Sure let’s do like that