Add include prerelease flag#299
Conversation
|
Thanks for this contribution! I'll try to look at it in my spare time. |
|
Hey @piotrooo, this should be ready for review now. Tests are passing and I've updated the PR description with the logic/explanation for the new behavior |
|
@piotrooo - Hi, just bumping this PR. I am also interested in this feature. |
|
@marshallavail, waiting for merge #317. Once it's merged, this PR will need to be aligned. This change requires a separate version. |
|
@piotrooo, I've merged the changes from main into the branch — we should be good to go now |
|
@sschuberth I'll try my best to move this PR forward. |
ed5f150 to
18a4ebe
Compare
|
@aqding First of all, sorry 🙏 for the long wait on the review and feedback. @sschuberth I'm going to merge this into main, but I won't release a new version until you finish your PR. |
Thanks, I'll rebase my PR. |
| <plugin> | ||
| <artifactId>maven-surefire-plugin</artifactId> | ||
| <version>3.5.3</version> | ||
| <version>2.22.2</version> |
There was a problem hiding this comment.
Why was this downgraded @piotrooo? This now causes
org.junit.platform.commons.JUnitException: OutputDirectoryProvider not available; probably due to unaligned versions of the junit-platform-engine and junit-platform-launcher jars on the classpath/module path.
for me. I'll upgrade it again as part of my PR.
Fixes #29
Adds the functionality equivalent of the
--include-prereleaseflag that will allow for including prerelease versions by default defined in the node semver repo here . The feature is accessible through a new methodSemver.satisfies(String range, boolean includePrerelease). All public methods will haveinclude-prereleasedefault to false to maintain backwards compatibility.Some of the processors are updated to be able to handle advanced ranges properly, as discussed in this issue. Architecturally,
Processoris changed from an interface to an abstract class to better handle some common state.To include proper support for
--include-prerelease, we need to add some additional logic for appending a prerelease identifier to certain ranges. For example, by default,1.xgets translated to>=1.0.0 <2.0.0. If we just used this same exact logic when considering prereleases, it will not work —1.0.0-betawill not satisfy the range, and2.0.0-betawill. So the actual correct range would then be>=1.0.0-0 <2.0.0-0, where0is the lowest possible prerelease identifier.However, note that we cannot just change the range to always be
>-1.0.0-0 <2.0.0-0, because that would mean anything with a prerelease identifier would satisfy the range, even if--include-prereleaseis not set. This has to do with how prerelease versions interact with comparators, as defined here.Something else that might be noticed is that, with
--include-prerelease,^1.2.3translates to>=1.2.3 <2.0.0-0, whereas^1.2translates to>=1.2.3-0 <2.0.0-0. This has to do with how x ranges are defined. Specifically, the definition is that:By this logic then, the lowest version that satisfies
1.2.3is just1.2.3(it just so happens to be the only version that satisfies that range, since a range that is a version is just satisfied by the version), while the lowest version that satisfies1.2is1.2.0-0. This is why in Tilde, Caret, and Hyphen ranges, we have the lower bound of the range use the0prerelease identifier if a minor or patch version is not specified.