Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 224456

Summary:	Bundle versioning scheme should be based on problem filtering and project preferences
Product:	[Eclipse Project] PDE	Reporter:	Olivier Thomann <Olivier_Thomann>
Component:	API Tools	Assignee:	Darin Wright <darin.eclipse>
Status:	VERIFIED FIXED	QA Contact:
Severity:	normal
Priority:	P3	CC:	bokowski, darin.eclipse, mober.at+eclipse, susan
Version:	3.4
Target Milestone:	3.4 M7
Hardware:	PC
OS:	Windows XP
Whiteboard:
Bug Depends on:
Bug Blocks:	225433

Description Olivier Thomann

2008-03-27 16:02:24 EDT

When the user decides that he/she wants to ignore a certain "compatibility" error, we should not propose a new bundle version that still consider this error.
Right now if the user renames a static field and decides this is fine as the field is a static field with a compile-time constant and therefore cannot break existing clients (binary compatible). It might be possible to break existing clients, but the user decides that this worths the risk.
So we should propose a new version as if the plugin only contains new APIs (micro + 1) and no API breakage (major + 1).

Comment 1 Martin Oberhuber

2008-03-27 16:10:11 EDT

See bug 222905 comment 17 for a sample scenario, as well as more comments.

Comment 2 Olivier Thomann

2008-03-28 09:15:59 EDT

My concern with this one is that the bundle version might not reflect changes applied to the bundle since the previous version. This might create a situation where some bundles should be compatible because their versions are within the version range and in reality they are not.

Comment 3 Darin Wright

2008-03-31 16:38:03 EDT

We need to investigate/consider this use case. It seems a few component owners are running into this problem.

Comment 4 Boris Bokowski

2008-03-31 16:57:48 EDT

We have another scenario in JFace, where we decided to change the value of a "public static final int" constant. This value is used as a style bit for a constructor, and the old value was wrong. We added code that detects when the old value is passed in, changing it to the correct value before passing it on to SWT.

I guess the "correct" way would have been to deprecate the existing constant and add a new one, but we felt that the additional work imposed on clients by doing that was not warranted.

Comment 5 Olivier Thomann

2008-04-01 09:59:24 EDT

Right now we have an inconsistency.
When changing the preferences, the bundle errors are not flagged, but when using the problem filter they are.
If the preferences are modified to "ignore" some problems, the corresponding problem is not reported by the builder.
When the problem is filtered, this is done after the bit has been set to "check" the bundle version.

We need a consistent story here. The current situation is confusing.

Comment 6 Darin Wright

2008-04-01 10:28:31 EDT

Olivier, I think we should change to do something like this:

* builder is invoked
* creates API problems, adds them to the problem reporter
* (the problem report does the filtering)
* after all building is complete, the builder checks with the problem reporter for specific kinds of problems that would effect bundle versions to decide if bundle version problems need to be added

This way, we avoid putting the decision in the delta. We would need new API on the problem reporter to ask for problems/or specific kinds of problems (what ever would work best).

Comment 7 Olivier Thomann

2008-04-01 10:43:31 EDT

I'll investigate it.

Comment 8 Olivier Thomann

2008-04-02 15:19:54 EDT

We must also check the existing markers in case of an incremental build to "rebuild" some files or simply remove the existing markers that are not relevant anymore. See bug 224983.

Comment 9 Olivier Thomann

2008-04-16 15:23:47 EDT

Released for 3.4M7.
Michael, please verify.

Comment 10 Olivier Thomann

2008-04-16 15:24:02 EDT

Released.

Comment 11 Darin Wright

2008-04-30 17:40:24 EDT

Re-opening. Looks like we still report bundle version problems even when related problems have been filtered.

Comment 12 Olivier Thomann

2008-04-30 22:47:33 EDT

Released for 3.4M7.
Darin, please verify.

Comment 13 Olivier Thomann

2008-04-30 22:47:44 EDT

Fixed.

Comment 14 Darin Wright

2008-05-01 09:55:34 EDT

Verified. Bundle version problems are now avoided if I filter associated problems, or set severities to ignore.