Re: [platform-dev] API changes in SDK

2019-06-13 Thread Lars Vogel 
Many, many, thanks, Mickael. Looking forward to have that check
automatically done in the Gerrit verification build.

On Wed, Jun 12, 2019 at 2:48 PM Mickael Istria  wrote:
>
> Hi all,
>
> See https://bugs.eclipse.org/bugs/show_bug.cgi?id=474156#c26 for a solution 
> that would make API errors fail Gerrit jobs (and in any builds when profile 
> is enabled).
> It could be the last time we have a thread about API breakage caused by 
> undisciplined committers or complex setup processes, enjoy it!
>
> Cheers,
> ___
> platform-dev mailing list
> [email protected]
> To change your delivery options, retrieve your password, or unsubscribe from 
> this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev



-- 
Eclipse Platform project co-lead
CEO vogella GmbH

Haindaalwisch 17a, 22395 Hamburg
Amtsgericht Hamburg: HRB 127058
Geschäftsführer: Lars Vogel, Jennifer Nerlich de Vogel
USt-IdNr.: DE284122352
Fax (040) 5247 6322, Email: [email protected], Web: http://www.vogella.com
___
platform-dev mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] API changes in SDK

2019-06-12 Thread Mickael Istria 
Hi all,

See https://bugs.eclipse.org/bugs/show_bug.cgi?id=474156#c26 for a solution
that would make API errors fail Gerrit jobs (and in any builds when profile
is enabled).
It could be the last time we have a thread about API breakage caused by
undisciplined committers or complex setup processes, enjoy it!

Cheers,
___
platform-dev mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] API changes in SDK

2019-05-12 Thread Andrey Loskutov 


Ed, see my answers below.

On 09.05.2019 10:28, Ed Merks wrote:
> Andrey,
>
> Comments below.
>
> On 09.05.2019 10:10, Andrey Loskutov wrote:
>> Ed,
>>
>> While we use Oomph in the lab (thanks for the tool!), I can't use
Oomph for SDK development,
> Why not?I've certainly used to to make contributions to the
Platform UI.

Yes. I believe SDK provisioning with Oompf is a great thing and lowers
the entry barrier for the new contributions significantly, and I really
appreciate all the effort spent for automating things with Oomph. As
I've already said, I'm not against Oomph in general - I've introduced
this internally in our lab and maintain our custom Oomph installation,
I've also contributed some bug fixes to Oomph.

So Oomph is great ... for some use cases!

I had few problems with Oomph in the past, and still have it. My biggest
concern and problem is that I want to use new nightly SDK builds *every
day*, but I don't want to have *some* random p2 updated "mix and match"
platform state. p2 never deletes old bundles from the install, only some
non human maintainable config files are updated, and so the updated
installation is a nightmare mix of new and old bundles, where nothing is
as it is supposed to be with a clean installation. Like with every
incremental compile, resulting artifacts state is not reproducible and
depends on the history of previous actions.

We all know how complicated and unpredictable p2 is, and we know that
Oomph adds another extra complexity layer on top of that. I need an SDK
installation that I can trust, because I need to know if that state I
observe is an SDK issue and not some p2/Oomph update issue. I have no
time to run daily investigation what broke the update or why the
installation doesn't behave as expected, clean all the obscure p2/oomph
caches, bundle pools, config files etc. It will simply ruin my daily
work. If I would be Oomph developer, I would for sure do this, but I'm
SDK developer and just want to consume Oomph, not debug it every day.

I write this because of my personal experience. I'm updating our
internal Oomph based installation for our lab every 1-2 months. Almost
every time I deploy an updated update site and test drive the update
with Oomph I observe some oddities, which may or may not be caused by
Oomph or p2 or network or new platform patches - I have no idea because
it is extremely time consuming to debug p2/update troubles, especially
with Oomph extra layer on top. So I can't afford such investigation
*every day*, not even monthly.

>>   and also Oomph leads to problems where occasional change of some
preference leads to the "automatically" wrong setup.
> This is very non-concrete.  I know for example that JDT occasionally
has null pointer exceptions while importing a new project (I see this on
the forum daily), but that's hardly an argument to say JDT leads to
problems so can't be used.

It is not because of bugs alone, I believe Oomph current state is mostly
acceptable (I haven't reported Oomph bugs for a year or so). My biggest
issue with Oomph is that thanks Oomph people don't even know what they
*need* to know, and if they change occasionally some important setting,
Oomph happily remembers that. After all, people have troubles, delete
the workspace (because they know that deleting workspace "fixes"
issues), create new one and Oomph happily applies saved wrong user
settings. After that people blindly do wrong things with the assumption
that everything is properly setup, and if you ask why do they do this,
they answer: "I haven't changed anything"!

Oomph (like any other advanced technology that simplifies our life)
changes developers to consumers. This is OK for a *usual* application
developers or for an *occasional* SDK contributors that don't need/want
to know how they tools are working, but as SDK maintainers we must know
our tools and must know how they work, because if we fail, all the
downstream projects will be affected, including Oomph which will fail to
update your install because the bundle versions aren't properly updated
etc. So I believe it is required for all SDK developers to understand
what API and bundle versions are and how to maintain them. Understanding
it also means to know where to look for and what to do if something is
not working as expected.

>>   Oomph can't fully resolve the "human" factor.
> So I simply don't see the point of a long list of detailed manual
instructions that are only in an email.

I've sent email first because we had some API troubles recently, and
I've updated now wiki to include the notes I've sent. It was just a
matter of free time. See
https://wiki.eclipse.org/Platform/How_to_Contribute#.5B4.5D_Prepare_API_tooling.

--
Kind regards,
Andrey Loskutov

https://www.eclipse.org/user/aloskutov
-
Спасение утопающих - дело рук самих утопающих
-
___
platform-dev mailing list

Re: [platform-dev] API changes in SDK

2019-05-12 Thread Andrey Loskutov 

I've updated the Wiki, see
https://wiki.eclipse.org/Platform/How_to_Contribute#.5B4.5D_Prepare_API_tooling

Feel free to improve that.

On 09.05.2019 09:49, Rolf Theunissen wrote:

Hi,

For us new committers, are these rules documented anywhere? I cannot
find any references to these kind of rules in [1,2] and others.
It is kind of hard to follow a unknown, undocumented process.

Kind Regards,
Rolf

[1] https://wiki.eclipse.org/Platform_UI
[2] https://wiki.eclipse.org/Eclipse_Project


--
Kind regards,
Andrey Loskutov

https://www.eclipse.org/user/aloskutov
-
Спасение утопающих - дело рук самих утопающих
-
___
platform-dev mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] API changes in SDK

2019-05-11 Thread Ed Merks 

Nikita,

Of course you haven't bothered to report a problem.  And even if you 
did, in the end, I have to question why should I bother to fix setup 
problems for the platform in the first place when practically no one 
uses the results anyway.  I will just make sure the things I personally 
use, e.g., the setup for Platform UI, work for me.  Everyone else can 
joyfully have their own opinionated opinions and we can continue to have 
a glitchy development processes in need of copious documentation spread 
around in hard-to-find places.  None of that affects me personally and 
it's clearly futile to try to improve anything for anyone else.


So yes, it's highly unfortunate that the platform development setup is 
so complicated.   But even if it were simple, that still wouldn't be a 
good argument to do in manually.  The only good argument would be that 
there is no automatic approach that works.


Regards,
Ed


On 11.05.2019 11:48, Nikita Nemkin wrote:
On Fri, May 10, 2019 at 2:26 PM Ed Merks > wrote:


With the Oomph setup, the baseline is always set up automatically.
   There are Oomph setups for the entire darned Eclipse SDK along
with detailed documentation:

https://wiki.eclipse.org/Eclipse_Platform_SDK_Provisioning


I've had nothing but trouble with Oomph setup in the past. It's 
glitchy and opinionated.
In fact, the procedure described in the wiki fails for me even now 
(some generic text editor bundle is missing during installation).


It's unfortunate that platform development setup is so complicated 
that it has to be automated.


Best regards,
Nikita Nemkin

___
platform-dev mailing list
[email protected]
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
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] API changes in SDK

2019-05-11 Thread Nikita Nemkin 
On Fri, May 10, 2019 at 2:26 PM Ed Merks  wrote:

> With the Oomph setup, the baseline is always set up automatically.
> There are Oomph setups for the entire darned Eclipse SDK along with
> detailed documentation:
>
>   https://wiki.eclipse.org/Eclipse_Platform_SDK_Provisioning
>

I've had nothing but trouble with Oomph setup in the past. It's glitchy and
opinionated.
In fact, the procedure described in the wiki fails for me even now (some
generic text editor bundle is missing during installation).

It's unfortunate that platform development setup is so complicated that it
has to be automated.

Best regards,
Nikita Nemkin
___
platform-dev mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] API changes in SDK

2019-05-10 Thread Rolf Theunissen 

+1 for using Oomph setups.

If there wasn't an Oomph setup available for the Platform projects, I 
would probably not even started working on the platform project at all.
Having used Oomph in multiple projects, I can tell it makes 
bootstrapping your environment something you do over your coffee break. 
No need for long complex procedures, and consistency between the setups 
of all developers.


Op 5/10/2019 om 11:26 AM schreef Ed Merks:


Comments below.

On 10.05.2019 10:10, Vikas Chandra wrote:


>>If only the correct baseline were automatically set...

In a new workspace, for an API tooling enabled plugin, we always have 
an "error" that tells the user that there is no baseline.
Quickfix takes you to the page where baseline is added. After that, 
the user should understand and set the correct baseline.
Most of the the documentation is already there is Andrey's 1st 
email's link ( setting correct baseline and versioning).


With the Oomph setup, the baseline is always set up automatically.    
There are Oomph setups for the entire darned Eclipse SDK along with 
detailed documentation:


https://wiki.eclipse.org/Eclipse_Platform_SDK_Provisioning

So when I'm asked to help fix issues in the e4 workbench model I use 
exactly this approach to set up an IDE to work on the platform.ui 
repository, complete with the baseline set, and it tells me properly 
about problems resulting from regenerating the model.  I didn't have 
to read any instructions first.


But everyone else seems completely enamored with their individualized 
manual approach, no doubt keeping a workspace/installation alive as 
long as possible because creating a new one is so unpleasant.




>> And all the preferences too.

If you don't tinker with the preference, it remains the most optimum 
one. There is an option of restore default in preference

page. ( in case you have changed preference)

If you have some good suggestion or ideas to improve and automate, 
please feel free to open a bug and discuss.


Well, that's already done.  But I'm told it can't be used, even though 
I use it myself and it works for me.  If something doesn't work, I can 
fix that, but as I said, it works for me.


As an example of how easy it could be, just consider that these the 
only instructions one needs to set up an EMF development environment:


https://ci.eclipse.org/emf/

Drag and drop and your done.   All the necessary tools are installed,  
the projects are imported, organized in working sets, the right 
preferences are set for EMF development.  And I've tried to make it 
just as easy for *all *the platform's projects.  But in the end, I can 
only lead a horse to water...




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 
To: [email protected]
Date: 05/09/2019 11:20 PM
Subject: Re: [platform-dev] API changes in SDK
Sent by: [email protected]





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 sen

Re: [platform-dev] API changes in SDK

2019-05-10 Thread Ed Merks 

Comments below.

On 10.05.2019 10:10, Vikas Chandra wrote:


>>If only the correct baseline were automatically set...

In a new workspace, for an API tooling enabled plugin, we always have 
an "error" that tells the user that there is no baseline.
Quickfix takes you to the page where baseline is added. After that, 
the user should understand and set the correct baseline.
Most of the the documentation is already there is Andrey's 1st email's 
link ( setting correct baseline and versioning).


With the Oomph setup, the baseline is always set up automatically.    
There are Oomph setups for the entire darned Eclipse SDK along with 
detailed documentation:


  https://wiki.eclipse.org/Eclipse_Platform_SDK_Provisioning

So when I'm asked to help fix issues in the e4 workbench model I use 
exactly this approach to set up an IDE to work on the platform.ui 
repository, complete with the baseline set, and it tells me properly 
about problems resulting from regenerating the model.  I didn't have to 
read any instructions first.


But everyone else seems completely enamored with their individualized 
manual approach, no doubt keeping a workspace/installation alive as long 
as possible because creating a new one is so unpleasant.




>> And all the preferences too.

If you don't tinker with the preference, it remains the most optimum 
one. There is an option of restore default in preference

page. ( in case you have changed preference)

If you have some good suggestion or ideas to improve and automate, 
please feel free to open a bug and discuss.


Well, that's already done.  But I'm told it can't be used, even though I 
use it myself and it works for me.  If something doesn't work, I can fix 
that, but as I said, it works for me.


As an example of how easy it could be, just consider that these the only 
instructions one needs to set up an EMF development environment:


https://ci.eclipse.org/emf/

Drag and drop and your done.   All the necessary tools are installed,  
the projects are imported, organized in working sets, the right 
preferences are set for EMF development.  And I've tried to make it just 
as easy for *all *the platform's projects.  But in the end, I can only 
lead a horse to water...




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 
To: [email protected]
Date: 05/09/2019 11:20 PM
Subject: Re: [platform-dev] API changes in SDK
Sent by: [email protected]





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,
plea

Re: [platform-dev] API changes in SDK

2019-05-10 Thread Vikas Chandra 
>>If only the correct baseline were automatically set...

In a new workspace, for an API tooling enabled plugin, we always have an
"error" that tells the user that there is no baseline.
Quickfix takes you to the page where baseline is added. After that, the
user should understand and set the correct baseline.
Most of the the documentation is already there is Andrey's 1st email's link
( setting correct baseline and versioning).

>> And all the preferences too.

If you don't tinker with the preference, it remains the most optimum one.
There is an option of restore default in preference
page. ( in case you have changed preference)

If you have some good suggestion or ideas to improve and automate, please
feel free to open a bug and discuss.

Regards,
Vikas

Eclipse PDE lead,
IBM Rational
EGL D Block - Bangalore, India
Office Phone No : +91 - 80 - 41776506




From:   Ed Merks 
To: [email protected]
Date:   05/09/2019 11:20 PM
Subject:        Re: [platform-dev] API changes in SDK
Sent by:[email protected]



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 
  To: [email protected]
  Date: 05/09/2019 12:50 AM
  Subject: [platform-dev] API changes in SDK
  Sent by: [email protected]





  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

Re: [platform-dev] API changes in SDK

2019-05-09 Thread Ed Merks 
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 filterwhich 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 
To: [email protected]
Date: 05/09/2019 12:50 AM
Subject: [platform-dev] API changes in SDK
Sent by: [email protected]





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 p

Re: [platform-dev] API changes in SDK

2019-05-09 Thread Vikas Chandra 
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





From:   Andrey Loskutov 
To: [email protected]
Date:   05/09/2019 12:50 AM
Subject:[platform-dev] API changes in SDK
Sent by:[email protected]



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://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.eclipse.org_Version-5FNumbering&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=GX7Y0qkiGeGZucWtN4LNVw0zMQRk7c4he15Of0gDz44&m=oFUnPI-uVjDOFXC_2iciuUJfPXWRdpLCyAvVk8ZQvJI&s=US_c9WhA5waWSFB1-WPC9H9T1XpVTUV4sKrGej34FDQ&e=

[2]
https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.eclipse.org_Evolving-5FJava-2Dbased-5FAPIs&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=GX7Y0qkiGeGZucWtN4LNVw0zMQRk7c4he15Of0gDz44&m=oFUnPI-uVjDOFXC_2iciuUJfPXWRdpLCyAvVk8ZQvJI&s=q-TXqw22LNmyyuTCf57b5Zp5bdeVByUtzsoq54E_gvc&e=

[3]
https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.eclipse.org_Evolving-5FJava-2Dbased-5FAPIs-5F2&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=GX7Y0qkiGeGZucWtN4LNVw0zMQRk7c4he15Of0gDz44&m=oFUnPI-uVjDOFXC_2iciuUJfPXWRdpLCyAvVk8ZQvJI&s=rXXYCvVf9Oe8QLOA63-IzXc02t9Al0vFgALgnryKHoE&e=


Regards,
Andrey

--
Kind regards,
Andrey Loskutov

Re: [platform-dev] API changes in SDK

2019-05-09 Thread Lars Vogel 
Thanks, Dani. I will help with
https://bugs.eclipse.org/bugs/show_bug.cgi?id=547138

On Thu, May 9, 2019 at 3:02 PM Daniel Megert  wrote:
>
> OK, I looked at this.
>
> Almost all projects are taking those options from the workspace settings 
> (even if project specific settings are specified, see 
> https://bugs.eclipse.org/546861). Therefore, we could get the biggest 
> improvement by changing the minor/major version preferences from 'Warning' to 
> 'Error': I can do that if there are no objections.
>
> NOTE: Please do not start to discuss https://bugs.eclipse.org/546861in this 
> thread. Use the bug report itself.
>
> I also filed bug 547138: Every project should set minor and major version 
> options to 'Error'
>
> Dani
>
>
>
> From:Lars Vogel 
> To:"Eclipse platform general developers list." 
> 
> Date:09.05.2019 11:33
> Subject:Re: [platform-dev] API changes in SDK
> Sent by:[email protected]
> 
>
>
>
> Dani, if you open a bug for platform UI and list at least one project
> with the incorrect setting, I volunteer to fix all other projects in
> platform UI.
>
> I really dislike this "I know something but do not share it "
> impression I get from your answers. Complaining about a situation but
> refusing to contribute to am improvement is IMHO not good behavior.
>
> Even writing your emails took you most likely longer than reporting
> the issue via Bugzilla.
>
> Best regards, Lars
>
> On Thu, May 9, 2019 at 11:22 AM Daniel Megert  
> wrote:
> >
> > > Would be nice to see you contributing to this effort Dani and you already 
> > > seem to know the affected projects.
> >
> > No I don't. One has to look at each project.
> >
> > Maybe anyone who notices it in one of its projects just fixes it.
> >
> > Dani
> >
> >
> >
> > From:Lars Vogel 
> > To:"Eclipse platform general developers list." 
> > 
> > Date:09.05.2019 11:09
> > Subject:Re: [platform-dev] API changes in SDK
> > Sent by:[email protected]
> > 
> >
> >
> >
> > Would be nice to see you contributing to this effort Dani and you
> > already seem to know the affected projects.
> >
> > Best regards, Lars
> >
> > On Thu, May 9, 2019 at 11:07 AM Daniel Megert  
> > wrote:
> > >
> > > Everyone can do this ;-).
> > >
> > > Dani
> > >
> > >
> > >
> > > From:Lars Vogel 
> > > To:"Eclipse platform general developers list." 
> > > 
> > > Date:09.05.2019 10:49
> > > Subject:Re: [platform-dev] API changes in SDK
> > > Sent by:[email protected]
> > > 
> > >
> > >
> > >
> > > > One important addition here: some plug-ins and even the default 
> > > > workspace
> > >
> > > Dani, please open a bug for that and list the project which uses this
> > > project setting. We should adjust that.
> > >
> > > On Thu, May 9, 2019 at 10:42 AM Daniel Megert  
> > > wrote:
> > > >
> > > > Thanks Andrey for this reminder!
> > > >
> > > > > If after that you see API errors in the workspace,
> > > >
> > > > One important addition here: some plug-ins and even the default 
> > > > workspace have some problems being reported as warning. So, you also 
> > > > need to check whether there are new API related warnings. Even better, 
> > > > make sure that minor and major version issues (Version Management tab) 
> > > > are set to 'Error' on your project(s) and in your workspaces.
> > > >
> > > > Dani
> > > >
> > > >
> > > >
> > > > From:Andrey Loskutov 
> > > > To:[email protected]
> > > > Date:08.05.2019 21:20
> > > > Subject:[platform-dev] API changes in SDK
> > > > Sent by:[email protected]
> > > > 
> > > >
> > > >
> > > >
> > > > Hi all,
> > > >
> > > > If you do *not* contribute or review contributions for Eclipse platform
> > > > SDK, stop reading this mail NOW!
> > > >
> &g

Re: [platform-dev] API changes in SDK

2019-05-09 Thread Daniel Megert 
OK, I looked at this.

Almost all projects are taking those options from the workspace settings 
(even if project specific settings are specified, see 
https://bugs.eclipse.org/546861). Therefore, we could get the biggest 
improvement by changing the minor/major version preferences from 'Warning' 
to 'Error': I can do that if there are no objections.

NOTE: Please do not start to discuss https://bugs.eclipse.org/546861 in 
this thread. Use the bug report itself.

I also filed bug 547138: Every project should set minor and major version 
options to 'Error' 

Dani



From:   Lars Vogel 
To: "Eclipse platform general developers list." 

Date:   09.05.2019 11:33
Subject:        Re: [platform-dev] API changes in SDK
Sent by:[email protected]



Dani, if you open a bug for platform UI and list at least one project
with the incorrect setting, I volunteer to fix all other projects in
platform UI.

I really dislike this "I know something but do not share it "
impression I get from your answers. Complaining about a situation but
refusing to contribute to am improvement is IMHO not good behavior.

Even writing your emails took you most likely longer than reporting
the issue via Bugzilla.

Best regards, Lars

On Thu, May 9, 2019 at 11:22 AM Daniel Megert  
wrote:
>
> > Would be nice to see you contributing to this effort Dani and you 
already seem to know the affected projects.
>
> No I don't. One has to look at each project.
>
> Maybe anyone who notices it in one of its projects just fixes it.
>
> Dani
>
>
>
> From:Lars Vogel 
> To:    "Eclipse platform general developers list." 

> Date:09.05.2019 11:09
> Subject:Re: [platform-dev] API changes in SDK
> Sent by:[email protected]
> 
>
>
>
> Would be nice to see you contributing to this effort Dani and you
> already seem to know the affected projects.
>
> Best regards, Lars
>
> On Thu, May 9, 2019 at 11:07 AM Daniel Megert  
wrote:
> >
> > Everyone can do this ;-).
> >
> > Dani
> >
> >
> >
> > From:Lars Vogel 
> > To:"Eclipse platform general developers list." 

> > Date:09.05.2019 10:49
> > Subject:Re: [platform-dev] API changes in SDK
> > Sent by:[email protected]
> > 
> >
> >
> >
> > > One important addition here: some plug-ins and even the default 
workspace
> >
> > Dani, please open a bug for that and list the project which uses this
> > project setting. We should adjust that.
> >
> > On Thu, May 9, 2019 at 10:42 AM Daniel Megert 
 wrote:
> > >
> > > Thanks Andrey for this reminder!
> > >
> > > > If after that you see API errors in the workspace,
> > >
> > > One important addition here: some plug-ins and even the default 
workspace have some problems being reported as warning. So, you also need 
to check whether there are new API related warnings. Even better, make 
sure that minor and major version issues (Version Management tab) are set 
to 'Error' on your project(s) and in your workspaces.
> > >
> > > Dani
> > >
> > >
> > >
> > > From:Andrey Loskutov 
> > > To:[email protected]
> > > Date:08.05.2019 21:20
> > > Subject:[platform-dev] API changes in SDK
> > > Sent by:[email protected]
> > > 
> > >
> > >
> > >
> > > 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
>

Re: [platform-dev] API changes in SDK

2019-05-09 Thread Lars Vogel 
Dani, if you open a bug for platform UI and list at least one project
with the incorrect setting, I volunteer to fix all other projects in
platform UI.

I really dislike this "I know something but do not share it "
impression I get from your answers. Complaining about a situation but
refusing to contribute to am improvement is IMHO not good behavior.

Even writing your emails took you most likely longer than reporting
the issue via Bugzilla.

Best regards, Lars

On Thu, May 9, 2019 at 11:22 AM Daniel Megert  wrote:
>
> > Would be nice to see you contributing to this effort Dani and you already 
> > seem to know the affected projects.
>
> No I don't. One has to look at each project.
>
> Maybe anyone who notices it in one of its projects just fixes it.
>
> Dani
>
>
>
> From:Lars Vogel 
> To:"Eclipse platform general developers list." 
> 
> Date:    09.05.2019 11:09
> Subject:Re: [platform-dev] API changes in SDK
> Sent by:[email protected]
> 
>
>
>
> Would be nice to see you contributing to this effort Dani and you
> already seem to know the affected projects.
>
> Best regards, Lars
>
> On Thu, May 9, 2019 at 11:07 AM Daniel Megert  
> wrote:
> >
> > Everyone can do this ;-).
> >
> > Dani
> >
> >
> >
> > From:        Lars Vogel 
> > To:"Eclipse platform general developers list." 
> > 
> > Date:09.05.2019 10:49
> > Subject:Re: [platform-dev] API changes in SDK
> > Sent by:[email protected]
> > 
> >
> >
> >
> > > One important addition here: some plug-ins and even the default workspace
> >
> > Dani, please open a bug for that and list the project which uses this
> > project setting. We should adjust that.
> >
> > On Thu, May 9, 2019 at 10:42 AM Daniel Megert  
> > wrote:
> > >
> > > Thanks Andrey for this reminder!
> > >
> > > > If after that you see API errors in the workspace,
> > >
> > > One important addition here: some plug-ins and even the default workspace 
> > > have some problems being reported as warning. So, you also need to check 
> > > whether there are new API related warnings. Even better, make sure that 
> > > minor and major version issues (Version Management tab) are set to 
> > > 'Error' on your project(s) and in your workspaces.
> > >
> > > Dani
> > >
> > >
> > >
> > > From:Andrey Loskutov 
> > > To:[email protected]
> > > Date:08.05.2019 21:20
> > > Subject:[platform-dev] API changes in SDK
> > > Sent by:[email protected]
> > > 
> > >
> > >
> > >
> > > 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
> > &g

Re: [platform-dev] API changes in SDK

2019-05-09 Thread Daniel Megert 
> Would be nice to see you contributing to this effort Dani and you 
already seem to know the affected projects.

No I don't. One has to look at each project.

Maybe anyone who notices it in one of its projects just fixes it.

Dani



From:   Lars Vogel 
To: "Eclipse platform general developers list." 

Date:   09.05.2019 11:09
Subject:        Re: [platform-dev] API changes in SDK
Sent by:[email protected]



Would be nice to see you contributing to this effort Dani and you
already seem to know the affected projects.

Best regards, Lars

On Thu, May 9, 2019 at 11:07 AM Daniel Megert  
wrote:
>
> Everyone can do this ;-).
>
> Dani
>
>
>
> From:Lars Vogel 
> To:"Eclipse platform general developers list." 

> Date:        09.05.2019 10:49
> Subject:Re: [platform-dev] API changes in SDK
> Sent by:[email protected]
> 
>
>
>
> > One important addition here: some plug-ins and even the default 
workspace
>
> Dani, please open a bug for that and list the project which uses this
> project setting. We should adjust that.
>
> On Thu, May 9, 2019 at 10:42 AM Daniel Megert  
wrote:
> >
> > Thanks Andrey for this reminder!
> >
> > > If after that you see API errors in the workspace,
> >
> > One important addition here: some plug-ins and even the default 
workspace have some problems being reported as warning. So, you also need 
to check whether there are new API related warnings. Even better, make 
sure that minor and major version issues (Version Management tab) are set 
to 'Error' on your project(s) and in your workspaces.
> >
> > Dani
> >
> >
> >
> > From:Andrey Loskutov 
> > To:[email protected]
> > Date:08.05.2019 21:20
> > Subject:[platform-dev] API changes in SDK
> > Sent by:[email protected]
> > 
> >
> >
> >
> > 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

Re: [platform-dev] API changes in SDK

2019-05-09 Thread Lars Vogel 
Would be nice to see you contributing to this effort Dani and you
already seem to know the affected projects.

Best regards, Lars

On Thu, May 9, 2019 at 11:07 AM Daniel Megert  wrote:
>
> Everyone can do this ;-).
>
> Dani
>
>
>
> From:Lars Vogel 
> To:"Eclipse platform general developers list." 
> 
> Date:        09.05.2019 10:49
> Subject:Re: [platform-dev] API changes in SDK
> Sent by:[email protected]
> 
>
>
>
> > One important addition here: some plug-ins and even the default workspace
>
> Dani, please open a bug for that and list the project which uses this
> project setting. We should adjust that.
>
> On Thu, May 9, 2019 at 10:42 AM Daniel Megert  
> wrote:
> >
> > Thanks Andrey for this reminder!
> >
> > > If after that you see API errors in the workspace,
> >
> > One important addition here: some plug-ins and even the default workspace 
> > have some problems being reported as warning. So, you also need to check 
> > whether there are new API related warnings. Even better, make sure that 
> > minor and major version issues (Version Management tab) are set to 'Error' 
> > on your project(s) and in your workspaces.
> >
> > Dani
> >
> >
> >
> > From:Andrey Loskutov 
> > To:[email protected]
> > Date:08.05.2019 21:20
> > Subject:[platform-dev] API changes in SDK
> > Sent by:[email protected]
> > 
> >
> >
> >
> > 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

Re: [platform-dev] API changes in SDK

2019-05-09 Thread Daniel Megert 
Everyone can do this ;-).

Dani



From:   Lars Vogel 
To: "Eclipse platform general developers list." 

Date:   09.05.2019 10:49
Subject:    Re: [platform-dev] API changes in SDK
Sent by:[email protected]



> One important addition here: some plug-ins and even the default 
workspace

Dani, please open a bug for that and list the project which uses this
project setting. We should adjust that.

On Thu, May 9, 2019 at 10:42 AM Daniel Megert  
wrote:
>
> Thanks Andrey for this reminder!
>
> > If after that you see API errors in the workspace,
>
> One important addition here: some plug-ins and even the default 
workspace have some problems being reported as warning. So, you also need 
to check whether there are new API related warnings. Even better, make 
sure that minor and major version issues (Version Management tab) are set 
to 'Error' on your project(s) and in your workspaces.
>
> Dani
>
>
>
> From:Andrey Loskutov 
> To:[email protected]
> Date:08.05.2019 21:20
> Subject:[platform-dev] API changes in SDK
> Sent by:[email protected]
> 
>
>
>
> 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://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.eclipse.org_Version-5FNumbering&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=1UITCR5rxUZHSFczvfaNFK4ymEbEiccRX7VKchpqz0Y&m=VY0SGLqenrRWiJZ7xx-46IP-8rP2Wqrx7Q6wgTGV8uQ&s=CfBJHiNESb6NSVqQj0ZLs-lHfqhhh80NyJn4TiNSFBA&e=

> [2] 
https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.eclipse.org_Evolving-5FJava-2Dbased-5FAPIs&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=1UITCR5rxUZHSFczvfaNFK4ymEbEiccRX7VKchpqz0Y&m=VY0SGLqenrRWiJZ

Re: [platform-dev] API changes in SDK

2019-05-09 Thread Lars Vogel 
> One important addition here: some plug-ins and even the default workspace

Dani, please open a bug for that and list the project which uses this
project setting. We should adjust that.

On Thu, May 9, 2019 at 10:42 AM Daniel Megert  wrote:
>
> Thanks Andrey for this reminder!
>
> > If after that you see API errors in the workspace,
>
> One important addition here: some plug-ins and even the default workspace 
> have some problems being reported as warning. So, you also need to check 
> whether there are new API related warnings. Even better, make sure that minor 
> and major version issues (Version Management tab) are set to 'Error' on your 
> project(s) and in your workspaces.
>
> Dani
>
>
>
> From:Andrey Loskutov 
> To:[email protected]
> Date:08.05.2019 21:20
> Subject:[platform-dev] API changes in SDK
> Sent by:[email protected]
> 
>
>
>
> 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
> [email protected]
> 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
> [email protected]
> To change your delivery options, retrieve your password, or unsubscribe from 
> this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev



-- 
Eclipse Platform project co-lead
CEO vogella GmbH

Haindaalwisch 17a, 22395 Hamburg
Amtsgericht Hamburg: HRB 127058
Geschäftsführer: Lars Vogel, Jennifer Nerlich

Re: [platform-dev] API changes in SDK

2019-05-09 Thread Daniel Megert 
Thanks Andrey for this reminder!

> If after that you see API errors in the workspace, 

One important addition here: some plug-ins and even the default workspace 
have some problems being reported as warning. So, you also need to check 
whether there are new API related warnings. Even better, make sure that 
minor and major version issues (Version Management tab) are set to 'Error' 
on your project(s) and in your workspaces.

Dani



From:   Andrey Loskutov 
To: [email protected]
Date:   08.05.2019 21:20
Subject:[platform-dev] API changes in SDK
Sent by:[email protected]



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://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.eclipse.org_Version-5FNumbering&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=1UITCR5rxUZHSFczvfaNFK4ymEbEiccRX7VKchpqz0Y&m=C-wArFXzpG4l8S5NZQ18pSGRw0ZdC4rEOAZri74-sZQ&s=9RCPV29G38gxTnDyh3s5aSxFguU8mVE_H7zw2ZzYilw&e=

[2] 
https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.eclipse.org_Evolving-5FJava-2Dbased-5FAPIs&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=1UITCR5rxUZHSFczvfaNFK4ymEbEiccRX7VKchpqz0Y&m=C-wArFXzpG4l8S5NZQ18pSGRw0ZdC4rEOAZri74-sZQ&s=c3V8go3rdmVrxUiqFAnRZ4y4hC5L0W_yOyS8I7nLkQE&e=

[3] 
https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.eclipse.org_Evolving-5FJava-2Dbased-5FAPIs-5F2&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=1UITCR5rxUZHSFczvfaNFK4ymEbEiccRX7VKchpqz0Y&m=C-wArFXzpG4l8S5NZQ18pSGRw0ZdC4rEOAZri74-sZQ&s=KnXIRtwtMlHLeuqV_xvLBCU4ydGUmicCiWTgoQ7H894&e=


Regards,
Andrey

--
Kind regards,
Andrey Loskutov

https://urldefense.proofpoint.com/v2/url?u=https-3A__www.eclipse.org_user_aloskutov&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=1UITCR5rxUZHSFczvfaNFK4ymEbEiccRX7VKchpqz0Y&m=C-wArFXzpG4l8S5NZQ18pSGRw0ZdC4rEOAZri74-sZQ&s=G_gV19Z5MSg6N1CP9YYtvO5qdbpJVjqUavcaqPQtzV0&e=

-
Спасение утопающих - дело рук самих утопающих
-
___
platform-dev mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe 
from this list, visit
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.eclips

Re: [platform-dev] API changes in SDK

2019-05-09 Thread Andrey Loskutov 
All thinks I would fully agree ... but we don't have the automated CI build yet that can do this, and we *must* deliver stable and reliable API's.

So please consider that there are some "not agile" practices we *must* follow until we have a fully automated solution in CI.

It is not fun, it does not increase the diversity or attract new contributors, this is just work that *must* be done.

 

Kind regards,
Andrey Loskutov

Спасение утопающих - дело рук самих утопающих

https://www.eclipse.org/user/aloskutov

 
 

Gesendet: Donnerstag, 09. Mai 2019 um 10:21 Uhr
Von: "Mickael Istria" 
An: "Eclipse platform general developers list." 
Betreff: Re: [platform-dev] API changes in SDK



 

Hi,

 

While I understand Andrey and others and fully agree with them on the necessity and value of project respecting API rules and process for that -while I am one of the "worst citizen" on that matter in practice-, I think any proposal that involves enforcing developers to use or setup anything specific beyond the obvious is likely to fail. We cultivate diversity in the project and the community, and by this, we also cultivate "deviation" which ultimately drives to innovation which is something we're seeking.

So to me, enforcing a process to developers is 1. unrealistic because there will always be deviant people that we still want to feel welcome as they provide value and 2. not really desired as we want to constantly "lower the entry barrier" or "reduce maintenance effort" and such heavy process can really be expensive or blockers.

I also have the impression that this story is an instance of the agile's "People over process and tools" motto. Proposals that involve people to do thing differently are "process over people", proposals that enforce people to use a tools are "tools over people". Both should be avoided as final solution.

We see our community of contributors and committers very happy with Gerrit, good discussions happening here, people enjoy the review flow and the automated CI builds. So that's where people are and want to be when it comes to interacting and ensuring quality gates. This is where we should try to hook things; and since CI is just an instance of a build, it seems like putting some focus on automation of check at submission-time is something that would both reduce the need to follow a process and reduce the enforcement of tools. That is IMO the silver-bullet and where all consideration and effort on the topic of API versioning automation should be put. Let's continue the technical discussion about this silver-bullet in the related bugs ;)

___ platform-dev mailing list [email protected] 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
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] API changes in SDK

2019-05-09 Thread Lars Vogel 
Hi Mickael,

I'm also bad with API Tools.  Unfortunately I also have the impression
that least for deleting API the API tooling is buggy and as I'm mainly
the person who deletes API it usually hits me. Unfortunately I'm not
able to reproduce this bugs recently.

Examples for possible API tools issues are:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=532282
https://bugs.eclipse.org/bugs/show_bug.cgi?id=546741

Anyway, I completely agree with you with People over processes.
Currently we have lots of new contributors and committers and that is
great. That fact that we see more and more API tools errors should
result in improvements in our tooling to automate this step.

Best regards, Lars





On Thu, May 9, 2019 at 10:21 AM Mickael Istria  wrote:
>
>
> Hi,
>
> While I understand Andrey and others and fully agree with them on the 
> necessity and value of project respecting API rules and process for that 
> -while I am one of the "worst citizen" on that matter in practice-, I think 
> any proposal that involves enforcing developers to use or setup anything 
> specific beyond the obvious is likely to fail. We cultivate diversity in the 
> project and the community, and by this, we also cultivate "deviation" which 
> ultimately drives to innovation which is something we're seeking.
> So to me, enforcing a process to developers is 1. unrealistic because there 
> will always be deviant people that we still want to feel welcome as they 
> provide value and 2. not really desired as we want to constantly "lower the 
> entry barrier" or "reduce maintenance effort" and such heavy process can 
> really be expensive or blockers.
> I also have the impression that this story is an instance of the agile's 
> "People over process and tools" motto. Proposals that involve people to do 
> thing differently are "process over people", proposals that enforce people to 
> use a tools are "tools over people". Both should be avoided as final solution.
> We see our community of contributors and committers very happy with Gerrit, 
> good discussions happening here, people enjoy the review flow and the 
> automated CI builds. So that's where people are and want to be when it comes 
> to interacting and ensuring quality gates. This is where we should try to 
> hook things; and since CI is just an instance of a build, it seems like 
> putting some focus on automation of check at submission-time is something 
> that would both reduce the need to follow a process and reduce the 
> enforcement of tools. That is IMO the silver-bullet and where all 
> consideration and effort on the topic of API versioning automation should be 
> put. Let's continue the technical discussion about this silver-bullet in the 
> related bugs ;)
> ___
> platform-dev mailing list
> [email protected]
> To change your delivery options, retrieve your password, or unsubscribe from 
> this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev



--
Eclipse Platform project co-lead
CEO vogella GmbH

Haindaalwisch 17a, 22395 Hamburg
Amtsgericht Hamburg: HRB 127058
Geschäftsführer: Lars Vogel, Jennifer Nerlich de Vogel
USt-IdNr.: DE284122352
Fax (040) 5247 6322, Email: [email protected], Web: http://www.vogella.com
___
platform-dev mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] API changes in SDK

2019-05-09 Thread Ed Merks 

Andrey,

Comments below.

On 09.05.2019 10:10, Andrey Loskutov wrote:

Ed,

While we use Oomph in the lab (thanks for the tool!), I can't use Oomph for SDK 
development,

Why not?    I've certainly used to to make contributions to the Platform UI.

  and also Oomph leads to problems where occasional change of some preference leads to 
the "automatically" wrong setup.
This is very non-concrete.  I know for example that JDT occasionally has 
null pointer exceptions while importing a new project (I see this on the 
forum daily), but that's hardly an argument to say JDT leads to problems 
so can't be used.

  Oomph can't fully resolve the "human" factor.
No, of course not. Nothing can do that.  But it can fully resolve target 
platforms quickly, easily, and automatically; it will use the latest 
IBuild so will always be current.  Also it can fully resolve an API base 
line quickly and easily; it will use the previous release so that will 
be correct as well.  It will install the API tooling and any other tools 
that needed.  It can set any of these preferences you've mentioned.  So 
I simply don't see the point of a long list of detailed manual 
instructions that are only in an email.


But also assuming all the preferences are set, Oomph still can't solve the 
problem of not properly reviewing patches or selecting the right API problem 
fix.

No of course not.

So no, Oomph is not a silver bullet here.
No, but detailed manual instructions in an email that are a prerequisite 
for proper development practices are much less of a silver bullet.  
They're more of a gauntlet...


Kind regards,
Andrey Loskutov

Спасение утопающих - дело рук самих утопающих

https://www.eclipse.org/user/aloskutov



Gesendet: Donnerstag, 09. Mai 2019 um 10:00 Uhr
Von: "Ed Merks" 
An: [email protected]
Betreff: Re: [platform-dev] API changes in SDK

Andrey,

Perhaps folks should rather consider consistently using the same
automated setup so that everyone consistently see the same thing as
everyone else.  That's the purpose of the Oomph setup: to avoid all the
manual steps you describe here.

Regards,
Ed

___
platform-dev mailing list
[email protected]
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
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] API changes in SDK

2019-05-09 Thread Mickael Istria 
Hi,

While I understand Andrey and others and fully agree with them on the
necessity and value of project respecting API rules and process for that
-while I am one of the "worst citizen" on that matter in practice-, I think
any proposal that involves enforcing developers to use or setup anything
specific beyond the obvious is likely to fail. We cultivate diversity in
the project and the community, and by this, we also cultivate "deviation"
which ultimately drives to innovation which is something we're seeking.
So to me, enforcing a process to developers is 1. unrealistic because there
will always be deviant people that we still want to feel welcome as they
provide value and 2. not really desired as we want to constantly "lower the
entry barrier" or "reduce maintenance effort" and such heavy process can
really be expensive or blockers.
I also have the impression that this story is an instance of the agile's
"People over process and tools" motto. Proposals that involve people to do
thing differently are "process over people", proposals that enforce people
to use a tools are "tools over people". Both should be avoided as final
solution.
We see our community of contributors and committers very happy with Gerrit,
good discussions happening here, people enjoy the review flow and the
automated CI builds. So that's where people are and want to be when it
comes to interacting and ensuring quality gates. This is where we should
try to hook things; and since CI is just an instance of a build, it seems
like putting some focus on automation of check at submission-time is
something that would both reduce the need to follow a process and reduce
the enforcement of tools. That is IMO the silver-bullet and where all
consideration and effort on the topic of API versioning automation should
be put. Let's continue the technical discussion about this silver-bullet in
the related bugs ;)
___
platform-dev mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] API changes in SDK

2019-05-09 Thread Lars Vogel 
Hi Andrey,

thanks for the description.

Looks like API Tools errors are our new "You forgot to increase the
version". As such manual processes are errorprone, we added a
automatically check via Gerrit for the version increase and have seen
much less issues with that since.. Thanks to Mickael IIRC.

I suggest we also run the API Tools check in the Gerrit verification
build. In my native understanding of the API Tools tool chain I assume
this should be easy by simply adding a Ant runner step after the
normal Maven build. Lets discuss iin
https://bugs.eclipse.org/bugs/show_bug.cgi?id=474156

Best regards, Lars


On Wed, May 8, 2019 at 9:20 PM Andrey Loskutov  wrote:
>
> 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
> [email protected]
> To change your delivery options, retrieve your password, or unsubscribe from 
> this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev



--
Eclipse Platform project co-lead
CEO vogella GmbH

Haindaalwisch 17a, 22395 Hamburg
Amtsgericht Hamburg: HRB 127058
Geschäftsführer: Lars Vogel, Jennifer Nerlich de Vogel
USt-IdNr.: DE284122352
Fax (040) 5247 6322, Email: [email protected], Web: http://www.vogella.com
___
platform-dev mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] API changes in SDK

2019-05-09 Thread Andrey Loskutov 
Right, 

I forgot to add another points where we can help ourselves:
- contribute to the https://wiki.eclipse.org/Platform_UI wiki, describe the API 
maintenance
- add a "welcome page" for new contributors on thwe wiki, describe what is 
important to know (API maintenance, watching build/bugzilla/gerrit mails etc)
- improve the "welcome" mail for new contributors (if we have one?) to point to 
the wiki above
- TBC

Feel free to contribute!

Kind regards,
Andrey Loskutov

Спасение утопающих - дело рук самих утопающих

https://www.eclipse.org/user/aloskutov


> Gesendet: Donnerstag, 09. Mai 2019 um 09:49 Uhr
> Von: "Rolf Theunissen" 
> An: [email protected]
> Betreff: Re: [platform-dev] API changes in SDK
>
> Hi,
> 
> For us new committers, are these rules documented anywhere? I cannot 
> find any references to these kind of rules in [1,2] and others.
> It is kind of hard to follow a unknown, undocumented process.
> 
> Kind Regards,
> Rolf
> 
> [1] https://wiki.eclipse.org/Platform_UI
> [2] https://wiki.eclipse.org/Eclipse_Project

___
platform-dev mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] API changes in SDK

2019-05-09 Thread Andrey Loskutov 
Ed,

While we use Oomph in the lab (thanks for the tool!), I can't use Oomph for SDK 
development, and also Oomph leads to problems where occasional change of some 
preference leads to the "automatically" wrong setup. Oomph can't fully resolve 
the "human" factor.

But also assuming all the preferences are set, Oomph still can't solve the 
problem of not properly reviewing patches or selecting the right API problem 
fix.
So no, Oomph is not a silver bullet here.

Kind regards,
Andrey Loskutov

Спасение утопающих - дело рук самих утопающих

https://www.eclipse.org/user/aloskutov


> Gesendet: Donnerstag, 09. Mai 2019 um 10:00 Uhr
> Von: "Ed Merks" 
> An: [email protected]
> Betreff: Re: [platform-dev] API changes in SDK
>
> Andrey,
> 
> Perhaps folks should rather consider consistently using the same 
> automated setup so that everyone consistently see the same thing as 
> everyone else.  That's the purpose of the Oomph setup: to avoid all the 
> manual steps you describe here.
> 
> Regards,
> Ed

___
platform-dev mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] API changes in SDK

2019-05-09 Thread Ed Merks 

Andrey,

Perhaps folks should rather consider consistently using the same 
automated setup so that everyone consistently see the same thing as 
everyone else.  That's the purpose of the Oomph setup: to avoid all the 
manual steps you describe here.


Regards,
Ed


On 08.05.2019 21:20, Andrey Loskutov wrote:

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
[email protected]
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
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] API changes in SDK

2019-05-09 Thread Rolf Theunissen 

Hi,

For us new committers, are these rules documented anywhere? I cannot 
find any references to these kind of rules in [1,2] and others.

It is kind of hard to follow a unknown, undocumented process.

Kind Regards,
Rolf

[1] https://wiki.eclipse.org/Platform_UI
[2] https://wiki.eclipse.org/Eclipse_Project

Op 5/8/2019 om 9:20 PM schreef Andrey Loskutov:

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
[email protected]
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
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev