Bug 548537 - Exclude .settings/ for Git timestamp qualifier
Summary: Exclude .settings/ for Git timestamp qualifier
Status: NEW
Alias: None
Product: Platform
Classification: Eclipse Project
Component: Releng (show other bugs)
Version: 4.12   Edit
Hardware: All All
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: Platform-Releng-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on: 474156
Blocks:
  Show dependency tree
 
Reported: 2019-06-22 04:35 EDT by Mickael Istria CLA
Modified: 2019-06-26 06:27 EDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mickael Istria CLA 2019-06-22 04:35:17 EDT
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).
Comment 1 Mickael Istria CLA 2019-06-22 04:35:51 EDT
I'd like to wait for bug 474156 to be complete before we change that.
Comment 2 Michael Keppler CLA 2019-06-22 08:49:26 EDT
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?
Comment 3 Mickael Istria CLA 2019-06-22 10:19:48 EDT
(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.
Comment 4 Mickael Istria CLA 2019-06-25 05:39:34 EDT
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) ...
Comment 5 Mickael Istria CLA 2019-06-26 06:27:31 EDT
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.