Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 313794 - Two @since tags errors for org.eclipse.core.runtime.compatibility.registry fragment
Summary: Two @since tags errors for org.eclipse.core.runtime.compatibility.registry fr...
Status: RESOLVED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: Runtime (show other bugs)
Version: 3.6   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.7 RC1   Edit
Assignee: John Arthorne CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-05-20 14:59 EDT by Olivier Thomann CLA
Modified: 2011-04-29 08:56 EDT (History)
2 users (show)

See Also:
john.arthorne: review+

Attachments
Proposed fix (800 bytes, patch)
2010-05-26 12:50 EDT, Olivier Thomann CLA 		no flags Details | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Olivier Thomann CLA 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 CLA 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 CLA 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 CLA 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 CLA 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 CLA 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 CLA 2010-05-26 12:50:28 EDT 
Created attachment 170041 [details]
Proposed fix
Comment 7 Thomas Watson CLA 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 CLA 2011-04-29 08:56:19 EDT 
Olivier's fix looks good. I will release for RC1.
Comment 9 John Arthorne CLA 2011-04-29 08:56:57 EDT 
Released in HEAD.