Support specifying the baseline artifact version range #4317
Conversation
This can be used to select the desired baseline artifact if multiple versions of an artifact are available and to compare.
Test Results 603 files 603 suites 3h 59m 20s ⏱️ Results for commit 94dc487. |
HannesWell
added
the
backport-to-tycho-4.0.x
There was a problem hiding this comment.
I thing an explicit range is not really suitable here.
Also it is a bit unclear how to use it, maybe provide an integration-test to demonstrate the use-case would be helpful here also to prevent regressions in the future.
| * </p> | ||
| */ | ||
| @Parameter(defaultValue = "0.0.0", alias = "tycho.p2.baseline.versionRange") | ||
| private String baselineVersionRange = "0.0.0"; |
There was a problem hiding this comment.
This seems hardly usable, as one needs to explicitly configure the version per project (also 0.0.0 is not really a version range).
In PDE features we have the concept of a "match rule" that might be more sufficient here as we then can compute a version range based on the current project version.
There was a problem hiding this comment.
Yes that's what I meant in my initial comment with:
Instead of specifying the version range explicitly we could also define an enum similar to ReportBehavior to specify 'named version rules' for the baseline artifact, like
same-majorandlatest.
So I think the main question is what rules to support?
We could start simple and just have something like same-major and latest. Using the exact set of rules from PDE doesn't look suitable to me, because Perfect and Greater or Equal doesn't make sense in this context, because this mojo also checks for backward steps.
So besides same-major and latest actually only same-minor might be of interest.
But the names of the rules could be more speaking.
For the implementation we maybe could re-use PDE's new:
https://github.com/eclipse-pde/eclipse.pde/blob/3f973e87fd7ede513388e8ed870d1b65de438947/ui/org.eclipse.pde.core/src/org/eclipse/pde/core/plugin/VersionMatchRule.java
There was a problem hiding this comment.
So I think the main question is what rules to support?
We can just support what is useful today and add more if required, I think thats how its already done on some other places in Tycho
We could start simple and just have something like same-major and latest.
I would prefer to just use the same naming as for features as this is a P2 concept and we should not mix to much naming.
Using the exact set of rules from PDE doesn't look suitable to me, because Perfect and Greater or Equal doesn't make sense in this context,
Greater or equal is actually what is the default today, the only one not so useful might be "Perfect" that actually would never match anything.
For the implementation we maybe could re-use PDE's new:
Tycho has already org.eclipse.tycho.model.Feature.getVersionRange(ImportRef) we can simply generalize that method, so I don't think relying on PDE-UI in Tycho just to reuse an enum is very useful, if we ever do
it would of course be good to reuse as much as possible.
The idea was to use it for eclipse-jdt/eclipse.jdt.core#3027, but the old version might vanish anyways soon. |
So do we still need this? |
This can be used to select the desired baseline artifact if multiple versions of an artifact are available and to compare.
Instead of specifing the version range explicitly we could also define an enum similar to
ReportBehaviorto specify 'named version rules' for the baseline artifact, likesame-majorandlatest.