Closed stephan-herrmann closed 2 weeks ago
Version bump needed: Failed to execute goal org.eclipse.tycho.extras:tycho-p2-extras-plugin:4.0.8:compare-version-with-baselines (compare-attached-artifacts-with-release) on project org.eclipse.equinox.app: Only qualifier changed for (org.eclipse.equinox.app/1.7.100.v20240620-1529). Expected to have bigger x.y.z than what is available in baseline (1.7.100.v20240321-1445) -> [Help 1]
660 files ±0 660 suites ±0 1h 11m 32s :stopwatch: +34s 2 195 tests ±0 2 148 :white_check_mark: ±0 47 :zzz: ±0 0 :x: ±0 6 729 runs ±0 6 586 :white_check_mark: ±0 143 :zzz: ±0 0 :x: ±0
Results for commit 375d2181. ± Comparison against base commit 029433de.
:recycle: This comment has been updated with latest results.
testCoordinatedConfigurationOnBeforeRegisteredManagedService (org.osgi.test.cases.cm.junit.CMCoordinationTestCase) failed
Sorry, I can't find that test so I cannot test if this failure could possibly be related.
Sorry, I can't find that test so I cannot test if this failure could possibly be related.
It is not related.
Sorry, I can't find that test so I cannot test if this failure could possibly be related.
It is not related.
thanks.
I think it’s best for there to be one commit not 3.
I think I can do that with squash and merge button, but I’ve not tried that before.
That worked okay.
I think I can do that with squash and merge button, but I’ve not tried that before.
There's a first time for everything :)
(On other occasions people wanted to have version bumps separate from code changes, but perhaps that's only relevant in projects with BETA_JAVAXY branches).
Yes sometimes people want that. I think to make revert easier. But we don’t expect to revert this and the preceding state would never build successfully. 😬
And probably two separate version bump commits never make sense. 😱
Personally I generally amend and force push until I’m done. No one has complained so far. 😜
Yes sometimes people want that. I think to make revert easier. But we don’t expect to revert this and the preceding state would never build successfully.
Yes, that was the reason for the policy. Generally, it caused problems if we reverted and one I-Build to the next we had a version decrease. The other issue was if other changes happened after then the version decrease would become an issue also. But a straight revert in this project seems pretty rare vs. a new PR that fixes the issue on top of the existing changes.
Nothing I commit ever needs to be reverted. 👼 😜
When https://github.com/eclipse-jdt/eclipse.jdt.core/pull/2471 is merged, ecj will signal more casts as unnecessary.
With this PR I suggest to remove affected casts before new warnings will show up in the build.