Regards,
Vikas
------------------------------------------------------------------------
Eclipse PDE lead,
IBM Rational
EGL D Block - Bangalore, India
Office Phone No : +91 - 80 - 41776506
------------------------------------------------------------------------
Inactive hide details for Ed Merks ---05/09/2019 11:20:10 PM---If
only the correct baseline were automatically set... And all Ed Merks
---05/09/2019 11:20:10 PM---If only the correct baseline were
automatically set... And all the preferences too. I wonder how
From: Ed Merks <ed.me...@gmail.com>
To: platform-dev@eclipse.org
Date: 05/09/2019 11:20 PM
Subject: Re: [platform-dev] API changes in SDK
Sent by: platform-dev-boun...@eclipse.org
------------------------------------------------------------------------
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
------------------------------------------------------------------------
Inactive hide details for Andrey Loskutov ---05/09/2019
12:50:25 AM---Hi all, If you do *not* contribute or review
contributionAndrey Loskutov ---05/09/2019 12:50:25 AM---Hi
all, If you do *not* contribute or review contributions for
Eclipse platform
From: Andrey Loskutov _<losku...@gmx.de>_
<mailto:losku...@gmx.de>
To: _platform-dev@eclipse.org_ <mailto:platform-dev@eclipse.org>
Date: 05/09/2019 12:50 AM
Subject: [platform-dev] API changes in SDK
Sent by: _platform-dev-bounces@eclipse.org_
<mailto:platform-dev-boun...@eclipse.org>
------------------------------------------------------------------------
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@eclipse.org_ <mailto:platform-dev@eclipse.org>
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@eclipse.org_ <mailto:platform-dev@eclipse.org>
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@eclipse.org
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@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev
