|
If only the correct baseline were automatically set... And all
the preferences too. I wonder how we could possibly do that?
It seems pointless to me to record all these important details in
an email thread. Record them in a wiki, if you feel these are
important details that are best captured by documentation. Or
perhaps consider yet again that it might be better to record these
details in a script that is automatically applied and is used by
everyone so that no one needs to read wikis and/or email threads
with excruciating, manual, monkey-work tasks. The assertion
appears to be that apparently automation doesn't work for
inexplicable (and certainly unexplained) reasons. But for
goodness sake, we are tool developers, surely we can use tools for
all this! The term Luddite comes
to mind when I read a thread like this.
On 09.05.2019 18:43, Vikas Chandra
wrote:
I agree with Andrey in principle !
In short, before
submitting any gerrit patch, just keep the default workspace
settings and run API tools analysis
( clean->build all) after setting the
correct baseline. Ensure that none
of the settings has been made more lenient
(error changed to warning or ignore in project
setting) in the project.
There is always a quickfix - API tool filter which allows
user to override the API tool error based on user's
judgement/scenario. Common sense overrides
everything :) Suggestions on what can be improved in
API evolution/versioning would be good to have.
However, if version guidelines is not followed, then it can
cause
confusion to the end users.
If there is a
suggestion for changing the default settings that helps in
overall API evolution or any other
suggestion,
please file a bug. ( One such bug is already
filed by Dani ! )
Regards,
Vikas
------------------------------------------------------------------------
Eclipse PDE lead,
IBM
EGL D Block - Bangalore, India
------------------------------------------------------------------------
 Andrey Loskutov ---05/09/2019
12:50:25 AM---Hi all, If you do *not* contribute or review
contributions for Eclipse platform
From: Andrey
Loskutov <loskutov@xxxxxx>
To: platform-dev@xxxxxxxxxxx
Date: 05/09/2019
12:50 AM
Subject: [platform-dev]
API changes in SDK
Sent by: platform-dev-bounces@xxxxxxxxxxx
Hi all,
If you do *not* contribute or review contributions for Eclipse
platform
SDK, stop reading this mail NOW!
I wanted to remind you about some simple rules for Eclipse SDK
development, which are mandatory for all committers.
If the commit you want to merge contains an API change,
*before* merge
you should *always* load the patch into your IDE and run a
clean build
on related project.
Before doing so you should also make sure API tooling is
properly
configured, you use right API baseline and preferences are
properly set:
Preferences -> Plug in Development -> [x] Workspace
Plug-Ins override
target platform plugins...
Preferences -> Plug in Development -> [ ] Disable API
builder (must be
unset!)
Preferences -> Plug in Development -> Target Platform is
set to "Running
Platform" and you are using a recent nightly SDK build.
Preferences -> Plug in Development -> API Baselines
-> [x]
_latest_release_ (must be created manually and point to plain
SDK
installation of the last official SDK release).
If after that you see API errors in the workspace, please
consider to
read the proposed solution, compare that with the information
you can
get at [1], [2] and [3] and apply appropriated fix (or "-1" on
the
Gerrit patch).
There can be multiple possible API error fixes proposed by
PDE, but only
one can be the right one - unfortunately we still require the
power of
human brain to apply the *right* fix.
Please also note: human and computer make mistakes. Nobody is
perfect,
API tooling too. In doubt, ask on the list, but do not start
*decrement*
bundle versions or blindly increment them (because this always
fixes the
error, however may introduce a bigger one).
Basic rule is: during a development cycle (e.g. 4.12) we only
increment
one version segment *one time* according to the rules [1], [2]
and [3].
Only in case of human errors we have to bump the same version
segment
twice (once the wrong version is built and *published* we
can't simply
revert it so we must increase again...). We never decrement
versions if
they were already published via official SDK build.
Decision about *which* bundle version segment to change should
be always
based on [1], [2] and [3], not just on PDE "quick fix"
proposals. In
doubt - ask on the list.
Sure this is all complicated, sure this makes our life not
easier and
sure this could be improved and fully automated. But as long
as we don't
have an absolutely perfect, fully automated process we *must*
follow the
rules above.
There are also few places where you can help:
- Setup and use API tooling in your SDK workspace. Do it NOW!
- Improve API tooling by contributing to PDE. There are known
bugs and
there are known performance issues, but if nobody helps, they
will stay
forever.
- Contribute more maven checks that do *more* API checks
during Gerrit
build.
[1] https://wiki.eclipse.org/Version_Numbering
[2] https://wiki.eclipse.org/Evolving_Java-based_APIs
[3] https://wiki.eclipse.org/Evolving_Java-based_APIs_2
Regards,
Andrey
--
Kind regards,
Andrey Loskutov
https://www.eclipse.org/user/aloskutov
---------------------------------------------
Спасение утопающих - дело рук самих утопающих
---------------------------------------------
_______________________________________________
platform-dev mailing list
platform-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev
_______________________________________________
platform-dev mailing list
platform-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev
|
