Petr, is there any summary of what the APIs do and what other modules
use them or will have to use them? That would be helpful for thinking
about your proposal. Thanks.

In short the framework is built around Suggestion (and
SuggestionManager) class. Modules can create suggestions as side
effect of their computations and push them to the manager or register
themself (as providers) with the framework to get pull suggestion
retrieval queries.

All modules can provide suggestions. The pull approach sometimes
overlaps with currently used check&fix actions/wizards. The difference
is in workflow (assuming current implementation).

Right now it's used by all tasklist submodules. There is also one
known fork attempt by external developer.

Sound like the change is not too controversial and we can go for fast
track review. Petre, please announce it to nbdev to double check if
anybody was using the current API.

My opinion is that the proposed solution (option B) is the best we can do.

Drawback of B is that we will not have good answer to any 3rd party
contributor trying to plug into the tasklist. Answer "there is no api"
is not too satisfying, answer "you have to have impl dependency" is a
bit better, but still, we should support an attempt to write nonstable
API module and publish it on autoupdate. If used by other
only-autoupdate tasklist modules (I understand that there are few not
going to be stable), the quality would be guaranteed (e.g. it would be
useful) and would probably have a better chance to become the real api
(at least it would be in the right packages). 

I really do not want to support both internal API accessed using
implementation dependencies and unstable API. I do not see any real
advantage.

Non-stable modules can use implementation dependency. Such modules are
under development so they can accomodate to both new API or
implementation change without loosing any mayor investments.

From stable modules point of view API matters but they need only
stable API (I guess author will favour implementation dependency on
stable implementation version over dependning on unstable API).

I think that if Petr does not have time to create good and stable API
(option A) it's better not to create any API. IMO rushing with APIs
will not be any useful. The usefulness of unstable API can be tested
just as well with implementation dependency. Having the correct
packages is worse, not better, since it blurs the boundary between
stable API and nonstable implementation code.

Removed, module renamed to org.netbeans.tasklistapi.

I read "B) Remove the API completely" as "B) Do not attempt to have
stable API" as inside this task is written: 

- repackage api to org.netbeans.modules.tasklist.clients
- repackage spi to org.netbeans.modules.tasklist.providers
- rename the module (there are the beta versions living around)
- set Public-Packages attribute to '-'
- force maintainers to establish tasklist-barracuda impl dependency

which indicates that there is an API. Then I think: Its stability
should be specified, and probably javadoc released which people should
treat as a stable as the stability category says. Imho, if want to
make the API stable someday, you have to advertise it. And release
under less than stable category seems to be the right option.

What is wrong with this issue? It is still listed as open fast track
request. Turning into something that is being tracked (p2 defect) so
the module owner has to act.

I believe that B) (i.e. what Peter has already done) is the right
solution for the time being. The current "api" is not only unstable,
but far from complete. 
Unfortunatelly, we don't currently have time to redesign the apis. The
only feasible solution thus is hiding the current "api" for the time
being and publishing stable and complete api later, when there's time
and demand for it.

Closing as fixed, as the APIs are removed as requested by this issue.