Community
Participate
Working Groups
See https://www.eclipse.org/lists/platform-dev/msg01734.html As a consequence, bundles whose last change in only a change in .settings/ without a version bump compared to baseline would need to have version bumped, or their qualifier would move back in time (and fail checks).
I'd like to wait for bug 474156 to be complete before we change that.
I've seen the mailing list thread, but I haven't understood where you expect that much benefit from excluding .settings/. I'd estimate that when 100 versions are created now, 99 of them will still exist with that exclusion in place. Therefore I don't see why you want to take the risk of getting different binaries from changed settings without a version increase. That being said, this issue is about adding .settings/ to <jgit.ignore>, right?
(In reply to Michael Keppler from comment #2) > I've seen the mailing list thread, but I haven't understood where you expect > that much benefit from excluding .settings/. I'd estimate that when 100 > versions are created now, 99 of them will still exist with that exclusion in > place. Therefore I don't see why you want to take the risk of getting > different binaries from changed settings without a version increase. That was my expectation too, but when working on API Tools automation, I hit a case that prove me wrong: it happens that many bundles only have a change in .settings and generate a not needed new version. > That being said, this issue is about adding .settings/ to <jgit.ignore>, > right? Right.
Bundles whose version would have to be bumpled: * (org.eclipse.osgi.services/3.8.0.v20190206-1939). Baseline has 3.8.0.v20190206-2147) with delta: 0.0.0 * (org.eclipse.e4.ui.di/1.2.600.v20190428-1707). Baseline has 1.2.600.v20190510-1100) * (org.eclipse.ant.launching/1.2.500.v20190428-1847). Baseline has 1.2.500.v20190510-0606) * (org.eclipse.ltk.core.refactoring/3.10.100.v20190329-1313). Baseline has 3.10.100.v20190510-0840) * (org.eclipse.jdt.junit.core/3.10.300.v20190326-0607). Baseline has 3.10.300.v20190510-0840) * (org.eclipse.jdt.junit/3.11.400.v20190423-1630). Baseline has 3.11.400.v20190510-0840 * ...(probably many more, I stopped here so far) ...
I don't think it's worth making it high priority for M1. I personamly have.some more important/valuable things to work on at the moment in the Platform and don't believe I can safely commit to fix it soon enough.