Community
Participate
Working Groups
N20101010-2000 0. check out 'org.eclipse.ui.ide' from HEAD 1. change bundle version of 'org.eclipse.ui.ide' to 3.7.0 2. set API baseline to 3.6 3. open org.eclipse.ui.ide.OpenWithMenu 4. remove @noextend from class 5. save ==> no error on MANIFEST.MF Expected: problem reported on MANIFEST.MF to increase minor version number.
In this case, an API restriction has been relaxed (a class that was previously not extensible can now be extended). No new API has been added. Why should the minor version be increased? (the steps already say to increase it to 3.7.0).
(In reply to comment #1) > In this case, an API restriction has been relaxed (a class that was previously > not extensible can now be extended). No new API has been added. Why should the > minor version be increased? Since I can now extend that class, more API is available to me. Same as if a new API got added: there, you can also say, that the API is more relaxed, but still, we increase the service number.
In this case, don't you want to omit step 1 (which already manually increased the minor version)? i.e. the bundle version is 3.6.100, next you increase the API by removing the @noextend tag. The tooling should detect that the version should be increased to 3.7.0 form 3.6.100?
(In reply to comment #3) > In this case, don't you want to omit step 1 (which already manually increased > the minor version)? i.e. the bundle version is 3.6.100, next you increase the > API by removing the @noextend tag. The tooling should detect that the version > should be increased to 3.7.0 form 3.6.100? Mmh - I'm confused about my steps from comment 0. Let me check again and report back tomorrow.
(In reply to comment #4) > (In reply to comment #3) > > In this case, don't you want to omit step 1 (which already manually increased > > the minor version)? i.e. the bundle version is 3.6.100, next you increase the > > API by removing the @noextend tag. The tooling should detect that the version > > should be increased to 3.7.0 form 3.6.100? > Mmh - I'm confused about my steps from comment 0. Let me check again and > report back tomorrow. Sorry, the steps got copied from another bug. Step 1. needs to be removed.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
Vikas, please check whether this is still an issue,.
This still is a problem. Even a removal of @noimplement on interface is not forcing a minor version increase. However removal of @noreference works as I expected it to work.
Created attachment 277961 [details] Tentative fix Pending items 1) Add messages 2) Add test cases
Created attachment 277962 [details] Fixed for noinstantiate as well Pending items 1) Messages 2) Test cases
Created attachment 277970 [details] Updated fix
(In reply to Vikas Chandra from comment #11) > Created attachment 277970 [details] [diff] > Updated fix Since when did we switch back from Gerrit to text patches?
New Gerrit change created: https://git.eclipse.org/r/139379
Gerrit change https://git.eclipse.org/r/139379 was merged to [master]. Commit: http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?id=061975d6e68642349970d01343df49fd1b57bbde
verified in Version: 2019-06 (4.12) Build id: I20190406-1800
New Gerrit change created: https://git.eclipse.org/r/140267
Gerrit change https://git.eclipse.org/r/140267 was merged to [master]. Commit: http://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/commit/?id=b5a44469d3fa4b2d35543e37b2760db15d05720d
