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

Bug 313794

Summary:

Two @since tags errors for org.eclipse.core.runtime.compatibility.registry fragment

Product:

[Eclipse Project] Platform

Reporter:

Olivier Thomann <Olivier_Thomann>

Component:

Runtime

Assignee:

John Arthorne <john.arthorne>

Status:

RESOLVED FIXED

QA Contact:

Severity:

normal

Priority:

CC:

ob1.eclipse, tjwatson

Version:

3.6

Flags:

john.arthorne: review+

Target Milestone:

3.7 RC1

Hardware:

OS:

Windows XP

Whiteboard:

Attachments:

Description	Flags
Proposed fix	none

Description Olivier Thomann

2010-05-20 14:59:14 EDT

Using HEAD,

check out:
/org.eclipse.core.runtime.compatibility.registry
/org.eclipse.equinox.registry

from the cvs server.

Two @since tags errors are reported once the fragment org.eclipse.core.runtime.compatibility.registry is built.

The @since tags refer to host's version and not the fragment version.

Comment 1 Olivier Thomann

2010-05-26 10:46:43 EDT

Tom,

Why the @since tags are not pointing to 3.3 as this is the fragment version?
3.5 would refer to the host version.

Comment 2 Thomas Watson

2010-05-26 11:33:39 EDT

(In reply to comment #1)
> Tom,
> 
> Why the @since tags are not pointing to 3.3 as this is the fragment version?
> 3.5 would refer to the host version.

We found it strange that the API that the fragment replaces (which states @since 3.5) would all of a sudden change to @since 3.3 with the fragment installed.  I the correct thing to do would be to increment the compatibility fragment version to match the version of the host for API purposes.  In retrospect we should have increased the version of the fragment to 3.5 IMO when the new methods were added this release.

Comment 3 Olivier Thomann

2010-05-26 11:37:12 EDT

(In reply to comment #2)
> We found it strange that the API that the fragment replaces (which states
> @since 3.5) would all of a sudden change to @since 3.3 with the fragment
> installed.  I the correct thing to do would be to increment the compatibility
> fragment version to match the version of the host for API purposes.  In
> retrospect we should have increased the version of the fragment to 3.5 IMO when
> the new methods were added this release.
This would be more consistent. As it stands I don't plan to fix anything from the API tooling point of view.
From the fragment point of view, the API was added in 3.3.

If you increase the fragment's version to 3.5, then everything is fine again.

Should I move this bug to Equinox ?

Comment 4 Thomas Watson

2010-05-26 11:48:05 EDT

(In reply to comment #3)
> Should I move this bug to Equinox ?

Actually move it to Eclipse->Platform where the compatibility fragment lives.

Comment 5 Olivier Thomann

2010-05-26 11:51:25 EDT

Move to Platform/UI.
The fragment's version should match the host's version so that API addition gets a consistent version.

Comment 6 Olivier Thomann

2010-05-26 12:50:28 EDT

Created attachment 170041 [details]
Proposed fix

Comment 7 Thomas Watson

2010-05-26 14:22:37 EDT

I would rather not update the version at this point.  Not that I think it is terribly risky, but I don't think this issue is important enough to consider at this point.

Comment 8 John Arthorne

2011-04-29 08:56:19 EDT

Olivier's fix looks good. I will release for RC1.

Comment 9 John Arthorne

2011-04-29 08:56:57 EDT

Released in HEAD.