[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [eclipse-pmc] Adoption of newer Eclipse versions, and API Deprecation Policy
|
Hi all,
after chatting with Philippe on the phone, here is an
alternative wording:
In the Eclipse Project, we see that many clients have big problems
migrating their products to the yearly new Eclipse version:
-
API Compatibility: In spite of striving hard to
remain binary compatible, there are always cases where wrong API needs to be
rectified. This leads to effort on the client side. How can inevitable migration effort be
eased?
-
Bundle Internals: Clients use internal non-API
for a variety of reasons (e.g. "monkey see, monkey do" programming; not
understanding the clean API; functionality not available as API, or introduced
only after functionality was initially written). Becoming API clean would be
the obvious solution, but in many cases this is not possible in the time frame
available. How can we help clients become
API-clean, and how can we help protect investment where API cleanliness is
impossible?
-
Feature additions: Even if clients are API
clean, introduction of new features can make the clients look "old-fashioned"
or non-conforming in the latest incarnation of the Platform. Take Colors in
SWT trees for instance: before this feature, textual markup had to be used for
decorations, now colors are used. How can we
help clients detect usage of obsoleted features, and migrate to the new
feature more easily?
These are only some
examples where we see that in spite of remaining binary compatible, clients
cannot always migrate to newer Eclipse versions easily. Do others see similar
issues, or is this a pain that only IBM products see? Are there other pain
points to add to the list above? What can or should be done to ease the
situation? Here are some initial ideas:
- For (1)
API Compatibility: Create new Javadoc tag(s) and associated
tooling, such that clients can see when they use functionality that has
somehow changed. For instance: "@changed 3.4 passing null argument now leads
to no-op instead of performing default operation". API Tooling converts usage
of @changed API into task markers that clients can work on.
- For (2a)
Internals: Allow clients to run a report on their (closed-source)
code, such that all usage of non-API is properly reported and documented. This
report could be the discussion base such that we can understand what non-API
is "important" and/or help them find the correct API-clean counterpart for
non-API use. Ideally, such a "redirection" of non-API to API could be captured
in a way that is automated, i.e. the next client who sends in a report about
using a particular non-API is automatically pointed to the correct API-clean
way of doing something.
- For (2b)
Internals: Also, create a programme for contributed regression
tests: Allow clients to send in regression tests that mimic their specific
usage of non-API. Have the test run at Eclipse, but have the client be
resonsible for the test. Thanks to the test, changes in non-API are detected
much earlier and can be acted on properly.
- For (3)
Feature additions: Create a "soft deprecation" javadoc tag, which
tells clients that their use of functionality is still available (and won't go
away too soon), but also point them at how to use the newer, superseding
functionality (This is actually a variant of 2a).
As a corollary of
(3), we should also talk about formal API (and non-API) deprecation
policies, i.e. for how long we as a Community think that deprecated
functionality needs to be kept around, and how the Community should be informed
about deprecation. The goals of this discussion should be to
- Produce a clear set
of rules for Plugin Providers that, if followed, helps adopters of new
versions (e.g. how to document and tag changes).
- Produce a process
and tooling for Plugin Consumers that helps them (a) become more API clean,
(b) improve discussions about non-API, and (c) protect their investment in
non-API if necessary.
So
well that's quite a bit more than the 2 or 3 sentences that I asked for, but
that's how I tried to capture what I understood from what Philippe
said.
Comments and thoughts welcome...
Cheers,
--
Martin Oberhuber, Senior Member of Technical
Staff, Wind River
Target Management Project
Lead, DSDP PMC Member
Sure. How about ?
The cost
for migrating an Eclipse-based product to the next release is often far from
negligeable and for a range of reasons (including API compatibility, use of
other bundle internals, becoming obsoleted by feature additions, ...). We
should construct the list of pain points, and start thinking on how these
could be eased, baring in mind that ultimately, moving to a service release
should be a no brainer.
| From:
| "Oberhuber, Martin"
<Martin.Oberhuber@xxxxxxxxxxxxx>
|
| To:
| "Mike Wilson"
<Mike_Wilson@xxxxxxxxxx>, Philippe P Mulet/France/IBM@IBMFR
|
| Cc:
| eclipse-pmc@xxxxxxxxxxx
|
| Date:
| 01/07/2009 10:13 PM
|
| Subject:
| [eclipse-pmc] API Deprecation
Policy
|
| Sent by:
| eclipse-pmc-bounces@xxxxxxxxxxx |
Hi Mike, Philippe et al,
regarding the API Deprecation
discussion at the AC: I'm planning to send out a short reminder E-Mail to the
AC some time tomorrow. As part of that E-Mail, I could simply mention that the
Deprecation discussion is scheduled for the meeting. If you guys could come up
with a few brain teasers for that discussion (just 2 or 3 sentences), that
might help sparking off a nice discussion. What do you think?
Cheers,
--
Martin Oberhuber, Senior Member of Technical
Staff, Wind River
Target Management Project Lead, DSDP
PMC Member
http://www.eclipse.org/dsdp/tm
_______________________________________________
eclipse-pmc mailing
list
eclipse-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-pmc
Sauf
indication contraire ci-dessus:/ Unless stated otherwise above:
Compagnie
IBM France
Siège Social : Tour Descartes, 2, avenue Gambetta, La Défense 5,
92400 Courbevoie
RCS Nanterre 552 118 465
Forme Sociale :
S.A.S.
Capital Social : 609.751.783,30 €
SIREN/SIRET : 552 118 465
02430
