[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[swtbot-dev] concerning version, @since and API analysis
|
Hi
this issue was raised when working on a SWTBot task,
https://bugs.eclipse.org/bugs/show_bug.cgi?id=464687 and I was suggested
to discuss it in swtbot-dev list.
New API was introduced in SWTBot since the current released version,
2.2.1; the current development (and future release) version is 2.2.2
>From what I understand from
https://wiki.eclipse.org/Version_Numbering#When_to_change_the_minor_segment
the minor segment should be increased to reflect that, thus 2.3.0. It's
also true that the new API is not a huge change, so Mickael was
suggesting to keep 2.2.2, and to mark the new methods with @since 2.2.2,
instead of @since 2.2.
In a previous bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=426869 I
had enabled Eclipse API analysis (which, by the way, works really
nicely, with its tooling).
API analysis reports these problems:
- on the MANIFEST of bundles with new API, e.g.,
org.eclipse.swtbot.swt.finder, it says
"The minor version should be incremented in version 2.2.2, since new
APIs have been added since version 2.2.1" (suggesting to go to version
2.3.0)
- if I try to put @since 2.2.2 on new API methods, it says
"Invalid @since tag '2.2.2' on waitForJobs(Object, String); expecting
two fragments"
If incrementing to version 2.3.0 is not an option, I see an alternative
solution: use the API quickfix "Create a version number problem filter
on the MANIFEST". (these filters can then be removed in the future when
increasing the minor number).
Does that sound feasible?
I can take care of fixing API analysis problems according to this
strategy (there are bundles and classes that have to be fixed accordingly).
cheers
Lorenzo
--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
HOME: http://www.lorenzobettini.it
Xtext Book:
http://www.packtpub.com/implementing-domain-specific-languages-with-xtext-and-xtend/book
