Re: [platform-dev] Recent API Removal breaks clients

2020-09-23 Thread Mickael Istria 
On Wed, Sep 23, 2020 at 10:32 AM Jens Lideström  wrote:

> "This change is backwards compatible EXCEPT for the removal of
> deprecated things which have been clearly announced a long time in
> advance."


No need for a new segment for that. It's already the case for every minor
segment bump, as per Platform project rules (which are less "strict" here
than OSGi recommendations).
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Recent API Removal breaks clients

2020-09-23 Thread Jens Lideström 
Maybe it would be useful if the version number had an additional 
segement:


major.new-segment.minor.service

new-segment could be increased for removals, and an increase would 
signal something like this:


"This change is backwards compatible EXCEPT for the removal of 
deprecated things which have been clearly announced a long time in 
advance."


Of course this is just hypothetical, it's not possible to add a segment 
like this.


/Jens

2020-09-20 10:28 skrev Ed Merks:

Peter,

Comments below.

On 19.09.2020 11:51, Peter Kriens wrote:
So what is the purpose of version numbers if you start lying about 
their semantics?


The concern is that the cure (major version increments) is as
disruptive and painful as the disease (deleting/breaking API).
Assuming an API has been deprecated for a long time and that the
clients have all had sufficient time to stop using it and have done
so, the only remaining diseased part is in the bundle providing that
"API.".    Here the disease can be excised easily by a single
committer.   But, if we now also increment the major version number,
the resulting symptoms are exactly the same as the disease: all
clients are broken and all clients will yet again have to revisit all
their code to bump the upper bound of all their bundles.   This
approach guarantees that the entire downstream client base stops
working after each and every deletion.

Surely in this light, this is not a feasible strategy for the
platform's gigantic downstream ecoystem...



I agree that it semantic version does take an effort to get started 
with but from extensive experience I can promise you that this is a 
one time effort and pays off handsomely in much more control over the 
process.

If it were just within one project or the downstream consumer base is
small, that of course makes good sense.   But with the platform as
just the tip of the iceberg, I don't believe we should realistically
expect the entire ecosystem to be quite so enamored with this
approach.


However, having versions but then not using their semantics is 
probably the worst of both worlds.

It's all about balance.  However factually and technically correct you
are (and you definitely are),  the practical reality of a huge,
poorly-maintained, downstream ecosystem guarantees that this approach
will wipe out...


Kind regards,

Peter Kriens




On 18 Sep 2020, at 17:28, Lars Vogel  wrote:

Why is API removed from Eclipse without bumping the major version 
number?

I tried this once and we got furious feedback from the community that
is worse than anything else (see cross if you want to). People
maintain a max version and increasing the major version breaks them
completely So the PMC decided that planned deletions do not justify
major bumps.

Best regards, Lars

On Fri, Sep 18, 2020 at 5:11 PM Jonah Graham  
wrote:
Sorry to rehash old questions - but I wasn't active when this was 
first discussed. CDT has recently taken on this policy (but not used 
it yet):


Why is API removed from Eclipse without bumping the major version 
number? i.e the "In general, removing a deprecated API does NOT 
cause the increase of the major version segment." in 
https://wiki.eclipse.org/Eclipse/API_Central/API_Removal_Process


Thanks
Jonah

~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com


On Fri, 18 Sep 2020 at 09:43, Aleksandar Kurtakov 
 wrote:



On Fri, Sep 18, 2020 at 12:30 PM Aleksandar Kurtakov 
 wrote:



On Fri, Sep 18, 2020 at 11:27 AM Wim Jongman 
 wrote:



Should we not support older versions of Eclipse?


There is 2 years notice period so I would say do not support 
versions older than 2 years.


We provide LTS so it is not possible for everyone. It would also 
not catch the API break in the i-build.


API is deprecated for at least 2 years before being removed so if 
a project has deprecations free build with the 2 years old version 
it will work fine with the latest release.




1. The person that proposes the API change makes an impact 
analysis by searching all the Eclipse repositories, removal is 
abandoned if used > x%
2. Removal of API is sent to the mailing list of the project 
that uses the API so that we can fix things in time, especially 
when the project is in maintenance mode.


1. and 2. are not realistic if we go that path why don't we add 
Spring Tools or JBoss Tools which are one of the widely used 
plugins out there. Why not add Pydev too? Requiring to subscribe 
to project list to notify is a bit too much for me. There is a 
reason we have cross-project list. Effectively this proposal is 
to never ever change anything and let Eclipse Platform collapse 
under its own weight where we keep shipping multiple ways to do 
things - each with its own oddities.


Yes, we should add them as well. It is also about the thousands 
of consumers that we don't know.


And I really don't think that leaving three lines in Platform 
will cause Eclipse to collapse under its own weight. Java has 
never removed a deprecated method

Re: [platform-dev] Recent API Removal breaks clients

2020-09-21 Thread Wim Jongman 
I have filed a couple of bugs. Amongst which:

* *Bug 567200*  - Only
remove API one time a year
* *Bug 567203*  - Require
reason and impact assessment for API removal

The umbrella bug is here.

*Bug 567195*  - Optimize
the API removal process

Cheers, Wim


On Thu, Sep 17, 2020 at 9:05 PM Wim Jongman  wrote:

> Hi,
>
> jface.util.Assert was removed as well as platform.getJobManager.
>
> I love the cleanup but I hate the panic that this causes. I take care of
> WindowBuilder and Nebula releng. We do not build against the development
> version but against an older version. This is to protect us to not
> accidentally use a new API that is not compatible with the oldest Eclipse
> we support. This means that the build completes normally.
>
> Should we not support older versions of Eclipse?
>
> So now we have the removal of jface.util.Assert which breaks
> WindowBuilder. I did not see it because I did not use WB after Assert was
> removed only six weeks ago (over the holidays). Now the reports flow in
> because people are upgrading and we are no longer compatible with the
> latest eclipse.
>
> *I suggest adding three things to the API removal process.*
>
> 1. The person that proposes the API change makes an impact analysis by
> searching all the Eclipse repositories, removal is abandoned if used > x%
> 2. Removal of API is sent to the mailing list of the project that uses the
> API so that we can fix things in time, especially when the project is in
> maintenance mode.
> 3. API's are only removed before M1. This gives us some more time to catch
> and fix.
>
> Cheers,
>
> Wim
>
> * As an added bonus I now also have to deal with the removal of
> platform.getJobManager that break the IBM rational plugins that we use for
> our product. Now I have to chase IBM to fix something, I'd rather be
> fighting windmills.
>
>
>
>
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Recent API Removal breaks clients

2020-09-20 Thread Ed Merks 

Peter,

Comments below.

On 19.09.2020 11:51, Peter Kriens wrote:

So what is the purpose of version numbers if you start lying about their 
semantics?


The concern is that the cure (major version increments) is as disruptive 
and painful as the disease (deleting/breaking API). Assuming an API has 
been deprecated for a long time and that the clients have all had 
sufficient time to stop using it and have done so, the only remaining 
diseased part is in the bundle providing that "API.".    Here the 
disease can be excised easily by a single committer.   But, if we now 
also increment the major version number, the resulting symptoms are 
exactly the same as the disease: all clients are broken and all clients 
will yet again have to revisit all their code to bump the upper bound of 
all their bundles.   This approach guarantees that the entire downstream 
client base stops working after each and every deletion.


Surely in this light, this is not a feasible strategy for the platform's 
gigantic downstream ecoystem...




I agree that it semantic version does take an effort to get started with but 
from extensive experience I can promise you that this is a one time effort and 
pays off handsomely in much more control over the process.
If it were just within one project or the downstream consumer base is 
small, that of course makes good sense.   But with the platform as just 
the tip of the iceberg, I don't believe we should realistically expect 
the entire ecosystem to be quite so enamored with this approach.


However, having versions but then not using their semantics is probably the 
worst of both worlds.
It's all about balance.  However factually and technically correct you 
are (and you definitely are),  the practical reality of a huge, 
poorly-maintained, downstream ecosystem guarantees that this approach 
will wipe out...


Kind regards,

Peter Kriens




On 18 Sep 2020, at 17:28, Lars Vogel  wrote:


Why is API removed from Eclipse without bumping the major version number?

I tried this once and we got furious feedback from the community that
is worse than anything else (see cross if you want to). People
maintain a max version and increasing the major version breaks them
completely So the PMC decided that planned deletions do not justify
major bumps.

Best regards, Lars

On Fri, Sep 18, 2020 at 5:11 PM Jonah Graham  wrote:

Sorry to rehash old questions - but I wasn't active when this was first 
discussed. CDT has recently taken on this policy (but not used it yet):

Why is API removed from Eclipse without bumping the major version number? i.e the 
"In general, removing a deprecated API does NOT cause the increase of the major 
version segment." in https://wiki.eclipse.org/Eclipse/API_Central/API_Removal_Process

Thanks
Jonah

~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com


On Fri, 18 Sep 2020 at 09:43, Aleksandar Kurtakov  wrote:



On Fri, Sep 18, 2020 at 12:30 PM Aleksandar Kurtakov  
wrote:



On Fri, Sep 18, 2020 at 11:27 AM Wim Jongman  wrote:



Should we not support older versions of Eclipse?


There is 2 years notice period so I would say do not support versions older 
than 2 years.


We provide LTS so it is not possible for everyone. It would also not catch the 
API break in the i-build.


API is deprecated for at least 2 years before being removed so if a project has 
deprecations free build with the 2 years old version it will work fine with the 
latest release.




1. The person that proposes the API change makes an impact analysis by searching 
all the Eclipse repositories, removal is abandoned if used > x%
2. Removal of API is sent to the mailing list of the project that uses the API 
so that we can fix things in time, especially when the project is in 
maintenance mode.


1. and 2. are not realistic if we go that path why don't we add Spring Tools or 
JBoss Tools which are one of the widely used plugins out there. Why not add 
Pydev too? Requiring to subscribe to project list to notify is a bit too much 
for me. There is a reason we have cross-project list. Effectively this proposal 
is to never ever change anything and let Eclipse Platform collapse under its 
own weight where we keep shipping multiple ways to do things - each with its 
own oddities.


Yes, we should add them as well. It is also about the thousands of consumers 
that we don't know.

And I really don't think that leaving three lines in Platform will cause 
Eclipse to collapse under its own weight. Java has never removed a deprecated 
method or an API class. AFAICT, they are fine :)


That ^^ is no longer true for Java too. 
https://www.oracle.com/java/technologies/javase/jdk-11-relnote.html#Removed and 
continues in newer versions.


I just can't resist sending this link here 
https://www.eclipse.org/lists/cdt-dev/msg34634.html .
Java  and the overall software world are changing on an ever increasing pace - no matter 
whether we accept it, like it or not. Thus LTS (the old 10+ years) is gone - no

Re: [platform-dev] Recent API Removal breaks clients

2020-09-19 Thread Peter Kriens 
> On 19 Sep 2020, at 13:08, Wim Jongman  wrote:
> Instead of removing the method, we could perhaps tuck it away as a 
> deprecated, Javadoc-less oneliner at the end of the class.

Or start a new package with 'v2' in it like in Go. Then map all existing 
methods you want to keep to the new one. You could then make a compatibility 
library that gathers the old stuff.

Kind regards,

Peter Kriens






___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Recent API Removal breaks clients

2020-09-19 Thread Wim Jongman 
> or (perhaps a silly idea, don't hate me) create a class PlatformDeprecated
> that Platform extends and move dead wood there.
>

This cleans up Platform with almost 400 lines of deadwood.

https://git.eclipse.org/r/c/platform/eclipse.platform.runtime/+/169614
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Recent API Removal breaks clients

2020-09-19 Thread Wim Jongman 
>
> For JFace Assert, the deprecation is now 7 years old, and the alternative
> API to use has been available for 15 years.
> For platform.getJobManager(), the deprecation is now 6 years old, and the
> alternative API to use has been available for 15 years.
>

I don't disagree. I want to add one more point for your consideration.

Let's take a look at JFace Assert. A completely useless class. Not in use
by a lot of people. I can totally understand that this class has to go.
Good riddance.

Platform.getJobManager is IMHO a different case. Platform and PlatformUI
are the King and Queen of Eclipse Platform. Changing API in the Platform
class is much more likely to break a lot of clients.

Instead of removing the method, we could perhaps tuck it away as a
deprecated, Javadoc-less oneliner at the end of the class.

Not ideal, but IMO a better choice for our community.

PS

or (perhaps a silly idea, don't hate me) create a class PlatformDeprecated
that Platform extends and move dead wood there.
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Recent API Removal breaks clients

2020-09-19 Thread Peter Kriens 
So what is the purpose of version numbers if you start lying about their 
semantics?

I agree that it semantic version does take an effort to get started with but 
from extensive experience I can promise you that this is a one time effort and 
pays off handsomely in much more control over the process.

However, having versions but then not using their semantics is probably the 
worst of both worlds.

Kind regards,

Peter Kriens



> On 18 Sep 2020, at 17:28, Lars Vogel  wrote:
> 
>> Why is API removed from Eclipse without bumping the major version number?
> 
> I tried this once and we got furious feedback from the community that
> is worse than anything else (see cross if you want to). People
> maintain a max version and increasing the major version breaks them
> completely So the PMC decided that planned deletions do not justify
> major bumps.
> 
> Best regards, Lars
> 
> On Fri, Sep 18, 2020 at 5:11 PM Jonah Graham  wrote:
>> 
>> Sorry to rehash old questions - but I wasn't active when this was first 
>> discussed. CDT has recently taken on this policy (but not used it yet):
>> 
>> Why is API removed from Eclipse without bumping the major version number? 
>> i.e the "In general, removing a deprecated API does NOT cause the increase 
>> of the major version segment." in 
>> https://wiki.eclipse.org/Eclipse/API_Central/API_Removal_Process
>> 
>> Thanks
>> Jonah
>> 
>> ~~~
>> Jonah Graham
>> Kichwa Coders
>> www.kichwacoders.com
>> 
>> 
>> On Fri, 18 Sep 2020 at 09:43, Aleksandar Kurtakov  
>> wrote:
>>> 
>>> 
>>> 
>>> On Fri, Sep 18, 2020 at 12:30 PM Aleksandar Kurtakov  
>>> wrote:
 
 
 
 On Fri, Sep 18, 2020 at 11:27 AM Wim Jongman  wrote:
> 
> 
>>> Should we not support older versions of Eclipse?
>> 
>> 
>> There is 2 years notice period so I would say do not support versions 
>> older than 2 years.
> 
> 
> We provide LTS so it is not possible for everyone. It would also not 
> catch the API break in the i-build.
 
 
 API is deprecated for at least 2 years before being removed so if a 
 project has deprecations free build with the 2 years old version it will 
 work fine with the latest release.
 
> 
> 
>>> 1. The person that proposes the API change makes an impact analysis by 
>>> searching all the Eclipse repositories, removal is abandoned if used > 
>>> x%
>>> 2. Removal of API is sent to the mailing list of the project that uses 
>>> the API so that we can fix things in time, especially when the project 
>>> is in maintenance mode.
>> 
>> 
>> 1. and 2. are not realistic if we go that path why don't we add Spring 
>> Tools or JBoss Tools which are one of the widely used plugins out there. 
>> Why not add Pydev too? Requiring to subscribe to project list to notify 
>> is a bit too much for me. There is a reason we have cross-project list. 
>> Effectively this proposal is to never ever change anything and let 
>> Eclipse Platform collapse under its own weight where we keep shipping 
>> multiple ways to do things - each with its own oddities.
> 
> 
> Yes, we should add them as well. It is also about the thousands of 
> consumers that we don't know.
> 
> And I really don't think that leaving three lines in Platform will cause 
> Eclipse to collapse under its own weight. Java has never removed a 
> deprecated method or an API class. AFAICT, they are fine :)
 
 
 That ^^ is no longer true for Java too. 
 https://www.oracle.com/java/technologies/javase/jdk-11-relnote.html#Removed
  and continues in newer versions.
>>> 
>>> 
>>> I just can't resist sending this link here 
>>> https://www.eclipse.org/lists/cdt-dev/msg34634.html .
>>> Java  and the overall software world are changing on an ever increasing 
>>> pace - no matter whether we accept it, like it or not. Thus LTS (the old 
>>> 10+ years) is gone - no matter how hard it is tried it will become harder 
>>> and harder and admitting that can save us quite a lot of frustration. One 
>>> can look at what is the current "extended" support e.g. Firefox does it 
>>> roughly for a year. And we live in that reality - JVMs break API on 6 
>>> months, GTK will have more than a huge change very shortly (4.x), latest 
>>> MacOS requires changing the binaries produced due to new CPU architecture, 
>>> IE is being replaced by Chrome engine powered engine and so on and on. With 
>>> all that said - either projects start working on their deps to keep the 
>>> support for things for longer or it will be gone not because WE WANT to 
>>> remove it but because WE HAVE to in order to throw the next release out and 
>>> keep it working on the new versions of our dependencies.
>>> P.S. Before anyone brings the paid vs rest developers conversation again I 
>>> want to make smth crystal clear - No one just pays anyone to work on 
>>> whatever he wants in whatever way he

Re: [platform-dev] Recent API Removal breaks clients

2020-09-18 Thread Wim Jongman 
> A lot of people watch this list and are not interested in this discussion.


I think everybody is interested in this discussion. Discussions like these
are the exact purpose of this list.
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Recent API Removal breaks clients

2020-09-18 Thread Lars Vogel 
> Why is API removed from Eclipse without bumping the major version number?

I tried this once and we got furious feedback from the community that
is worse than anything else (see cross if you want to). People
maintain a max version and increasing the major version breaks them
completely So the PMC decided that planned deletions do not justify
major bumps.

Best regards, Lars

On Fri, Sep 18, 2020 at 5:11 PM Jonah Graham  wrote:
>
> Sorry to rehash old questions - but I wasn't active when this was first 
> discussed. CDT has recently taken on this policy (but not used it yet):
>
> Why is API removed from Eclipse without bumping the major version number? i.e 
> the "In general, removing a deprecated API does NOT cause the increase of the 
> major version segment." in 
> https://wiki.eclipse.org/Eclipse/API_Central/API_Removal_Process
>
> Thanks
> Jonah
>
> ~~~
> Jonah Graham
> Kichwa Coders
> www.kichwacoders.com
>
>
> On Fri, 18 Sep 2020 at 09:43, Aleksandar Kurtakov  wrote:
>>
>>
>>
>> On Fri, Sep 18, 2020 at 12:30 PM Aleksandar Kurtakov  
>> wrote:
>>>
>>>
>>>
>>> On Fri, Sep 18, 2020 at 11:27 AM Wim Jongman  wrote:


>> Should we not support older versions of Eclipse?
>
>
> There is 2 years notice period so I would say do not support versions 
> older than 2 years.


 We provide LTS so it is not possible for everyone. It would also not catch 
 the API break in the i-build.
>>>
>>>
>>> API is deprecated for at least 2 years before being removed so if a project 
>>> has deprecations free build with the 2 years old version it will work fine 
>>> with the latest release.
>>>


>> 1. The person that proposes the API change makes an impact analysis by 
>> searching all the Eclipse repositories, removal is abandoned if used > x%
>> 2. Removal of API is sent to the mailing list of the project that uses 
>> the API so that we can fix things in time, especially when the project 
>> is in maintenance mode.
>
>
> 1. and 2. are not realistic if we go that path why don't we add Spring 
> Tools or JBoss Tools which are one of the widely used plugins out there. 
> Why not add Pydev too? Requiring to subscribe to project list to notify 
> is a bit too much for me. There is a reason we have cross-project list. 
> Effectively this proposal is to never ever change anything and let 
> Eclipse Platform collapse under its own weight where we keep shipping 
> multiple ways to do things - each with its own oddities.


 Yes, we should add them as well. It is also about the thousands of 
 consumers that we don't know.

 And I really don't think that leaving three lines in Platform will cause 
 Eclipse to collapse under its own weight. Java has never removed a 
 deprecated method or an API class. AFAICT, they are fine :)
>>>
>>>
>>> That ^^ is no longer true for Java too. 
>>> https://www.oracle.com/java/technologies/javase/jdk-11-relnote.html#Removed 
>>> and continues in newer versions.
>>
>>
>> I just can't resist sending this link here 
>> https://www.eclipse.org/lists/cdt-dev/msg34634.html .
>> Java  and the overall software world are changing on an ever increasing pace 
>> - no matter whether we accept it, like it or not. Thus LTS (the old 10+ 
>> years) is gone - no matter how hard it is tried it will become harder and 
>> harder and admitting that can save us quite a lot of frustration. One can 
>> look at what is the current "extended" support e.g. Firefox does it roughly 
>> for a year. And we live in that reality - JVMs break API on 6 months, GTK 
>> will have more than a huge change very shortly (4.x), latest MacOS requires 
>> changing the binaries produced due to new CPU architecture, IE is being 
>> replaced by Chrome engine powered engine and so on and on. With all that 
>> said - either projects start working on their deps to keep the support for 
>> things for longer or it will be gone not because WE WANT to remove it but 
>> because WE HAVE to in order to throw the next release out and keep it 
>> working on the new versions of our dependencies.
>> P.S. Before anyone brings the paid vs rest developers conversation again I 
>> want to make smth crystal clear - No one just pays anyone to work on 
>> whatever he wants in whatever way he wants if you find such a place let me 
>> know. With faster and faster ecosystem changes an official task (aka being 
>> paid for) for some of us is "REDUCE MAINTENANCE COST" and getting the blame 
>> for not going to the extend that someone would like to see it while moving 
>> like a snake (compared to other projects with which you compete for 
>> resources) definitely has a positive and thankful effect for spending "my 
>> own time" (quotes on purpose) trying to keep things going in the least 
>> disruptive way possible while still preserving people to work on the "thing".
>> P.S. 2 I would love to be pointed to another RCP/IDE platform that

Re: [platform-dev] Recent API Removal breaks clients

2020-09-18 Thread Jonah Graham 
Sorry to rehash old questions - but I wasn't active when this was first
discussed. CDT has recently taken on this policy (but not used it yet):

Why is API removed from Eclipse without bumping the major version number?
i.e the "In general, removing a deprecated API does NOT cause the increase
of the major version segment." in
https://wiki.eclipse.org/Eclipse/API_Central/API_Removal_Process

Thanks
Jonah

~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com


On Fri, 18 Sep 2020 at 09:43, Aleksandar Kurtakov 
wrote:

>
>
> On Fri, Sep 18, 2020 at 12:30 PM Aleksandar Kurtakov 
> wrote:
>
>>
>>
>> On Fri, Sep 18, 2020 at 11:27 AM Wim Jongman 
>> wrote:
>>
>>>
>>> Should we not support older versions of Eclipse?
>

 There is 2 years notice period so I would say do not support versions
 older than 2 years.

>>>
>>> We provide LTS so it is not possible for everyone. It would also not
>>> catch the API break in the i-build.
>>>
>>
>> API is deprecated for at least 2 years before being removed so if a
>> project has deprecations free build with the 2 years old version it will
>> work fine with the latest release.
>>
>>
>>>
>>> 1. The person that proposes the API change makes an impact analysis by
> searching all the Eclipse repositories, removal is abandoned if used > x%
> 2. Removal of API is sent to the mailing list of the project that uses
> the API so that we can fix things in time, especially when the project is
> in maintenance mode.
>

 1. and 2. are not realistic if we go that path why don't we add Spring
 Tools or JBoss Tools which are one of the widely used plugins out there.
 Why not add Pydev too? Requiring to subscribe to project list to notify is
 a bit too much for me. There is a reason we have cross-project list.
 Effectively this proposal is to never ever change anything and let Eclipse
 Platform collapse under its own weight where we keep shipping multiple ways
 to do things - each with its own oddities.

>>>
>>> Yes, we should add them as well. It is also about the thousands of
>>> consumers that we don't know.
>>>
>>> And I really don't think that leaving three lines in Platform will cause
>>> Eclipse to collapse under its own weight. Java has never removed a
>>> deprecated method or an API class. AFAICT, they are fine :)
>>>
>>
>> That ^^ is no longer true for Java too.
>> https://www.oracle.com/java/technologies/javase/jdk-11-relnote.html#Removed
>> and continues in newer versions.
>>
>
> I just can't resist sending this link here
> https://www.eclipse.org/lists/cdt-dev/msg34634.html .
> Java  and the overall software world are changing on an ever increasing
> pace - no matter whether we accept it, like it or not. Thus LTS (the old
> 10+ years) is gone - no matter how hard it is tried it will become harder
> and harder and admitting that can save us quite a lot of frustration. One
> can look at what is the current "extended" support e.g. Firefox does it
> roughly for a year. And we live in that reality - JVMs break API on 6
> months, GTK will have more than a huge change very shortly (4.x), latest
> MacOS requires changing the binaries produced due to new CPU architecture,
> IE is being replaced by Chrome engine powered engine and so on and on. With
> all that said - either projects start working on their deps to keep the
> support for things for longer or it will be gone not because WE WANT to
> remove it but because WE HAVE to in order to throw the next release out and
> keep it working on the new versions of our dependencies.
> P.S. Before anyone brings the paid vs rest developers conversation again I
> want to make smth crystal clear - No one just pays anyone to work on
> whatever he wants in whatever way he wants if you find such a place let me
> know. With faster and faster ecosystem changes an official task (aka being
> paid for) for some of us is "REDUCE MAINTENANCE COST" and getting the blame
> for not going to the extend that someone would like to see it while moving
> like a snake (compared to other projects with which you compete for
> resources) definitely has a positive and thankful effect for spending "my
> own time" (quotes on purpose) trying to keep things going in the least
> disruptive way possible while still preserving people to work on the
> "thing".
> P.S. 2 I would love to be pointed to another RCP/IDE platform that takes
> backward compatibility more seriously than Eclipse TLP!!!
>
>
>>
>>
>>>
>>> Cheers,
>>>
>>> Wim
>>>
>>> ___
>>> platform-dev mailing list
>>> platform-dev@eclipse.org
>>> To unsubscribe from this list, visit
>>> https://www.eclipse.org/mailman/listinfo/platform-dev
>>>
>>
>>
>> --
>> Alexander Kurtakov
>> Red Hat Eclipse Team
>>
>
>
> --
> Alexander Kurtakov
> Red Hat Eclipse Team
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit
>

Re: [platform-dev] Recent API Removal breaks clients

2020-09-18 Thread Wim Jongman 
Brothers,

I think we all can see each other's position. Our API must be kept clean
but we also don't want to break the projects that rely on our platform.

The fact that this discussion is coming back is an indicator that some
things can be improved.

So if we can all agree on that, let's see if we can implement _all_ of the
following.

1. Purge deprecated API as we do now.
2. Define the criteria for a drawback request.
3. Implement a better warning system.

If all say aye, I will open bugs for points 2 and 3.

Cheers,

Wim










On Fri, Sep 18, 2020 at 3:43 PM Aleksandar Kurtakov 
wrote:

>
>
> On Fri, Sep 18, 2020 at 12:30 PM Aleksandar Kurtakov 
> wrote:
>
>>
>>
>> On Fri, Sep 18, 2020 at 11:27 AM Wim Jongman 
>> wrote:
>>
>>>
>>> Should we not support older versions of Eclipse?
>

 There is 2 years notice period so I would say do not support versions
 older than 2 years.

>>>
>>> We provide LTS so it is not possible for everyone. It would also not
>>> catch the API break in the i-build.
>>>
>>
>> API is deprecated for at least 2 years before being removed so if a
>> project has deprecations free build with the 2 years old version it will
>> work fine with the latest release.
>>
>>
>>>
>>> 1. The person that proposes the API change makes an impact analysis by
> searching all the Eclipse repositories, removal is abandoned if used > x%
> 2. Removal of API is sent to the mailing list of the project that uses
> the API so that we can fix things in time, especially when the project is
> in maintenance mode.
>

 1. and 2. are not realistic if we go that path why don't we add Spring
 Tools or JBoss Tools which are one of the widely used plugins out there.
 Why not add Pydev too? Requiring to subscribe to project list to notify is
 a bit too much for me. There is a reason we have cross-project list.
 Effectively this proposal is to never ever change anything and let Eclipse
 Platform collapse under its own weight where we keep shipping multiple ways
 to do things - each with its own oddities.

>>>
>>> Yes, we should add them as well. It is also about the thousands of
>>> consumers that we don't know.
>>>
>>> And I really don't think that leaving three lines in Platform will cause
>>> Eclipse to collapse under its own weight. Java has never removed a
>>> deprecated method or an API class. AFAICT, they are fine :)
>>>
>>
>> That ^^ is no longer true for Java too.
>> https://www.oracle.com/java/technologies/javase/jdk-11-relnote.html#Removed
>> and continues in newer versions.
>>
>
> I just can't resist sending this link here
> https://www.eclipse.org/lists/cdt-dev/msg34634.html .
> Java  and the overall software world are changing on an ever increasing
> pace - no matter whether we accept it, like it or not. Thus LTS (the old
> 10+ years) is gone - no matter how hard it is tried it will become harder
> and harder and admitting that can save us quite a lot of frustration. One
> can look at what is the current "extended" support e.g. Firefox does it
> roughly for a year. And we live in that reality - JVMs break API on 6
> months, GTK will have more than a huge change very shortly (4.x), latest
> MacOS requires changing the binaries produced due to new CPU architecture,
> IE is being replaced by Chrome engine powered engine and so on and on. With
> all that said - either projects start working on their deps to keep the
> support for things for longer or it will be gone not because WE WANT to
> remove it but because WE HAVE to in order to throw the next release out and
> keep it working on the new versions of our dependencies.
> P.S. Before anyone brings the paid vs rest developers conversation again I
> want to make smth crystal clear - No one just pays anyone to work on
> whatever he wants in whatever way he wants if you find such a place let me
> know. With faster and faster ecosystem changes an official task (aka being
> paid for) for some of us is "REDUCE MAINTENANCE COST" and getting the blame
> for not going to the extend that someone would like to see it while moving
> like a snake (compared to other projects with which you compete for
> resources) definitely has a positive and thankful effect for spending "my
> own time" (quotes on purpose) trying to keep things going in the least
> disruptive way possible while still preserving people to work on the
> "thing".
> P.S. 2 I would love to be pointed to another RCP/IDE platform that takes
> backward compatibility more seriously than Eclipse TLP!!!
>
>
>>
>>
>>>
>>> Cheers,
>>>
>>> Wim
>>>
>>> ___
>>> platform-dev mailing list
>>> platform-dev@eclipse.org
>>> To unsubscribe from this list, visit
>>> https://www.eclipse.org/mailman/listinfo/platform-dev
>>>
>>
>>
>> --
>> Alexander Kurtakov
>> Red Hat Eclipse Team
>>
>
>
> --
> Alexander Kurtakov
> Red Hat Eclipse Team
> ___
> platform-dev mailing

Re: [platform-dev] Recent API Removal breaks clients

2020-09-18 Thread Aleksandar Kurtakov 
On Fri, Sep 18, 2020 at 12:30 PM Aleksandar Kurtakov 
wrote:

>
>
> On Fri, Sep 18, 2020 at 11:27 AM Wim Jongman 
> wrote:
>
>>
>> Should we not support older versions of Eclipse?

>>>
>>> There is 2 years notice period so I would say do not support versions
>>> older than 2 years.
>>>
>>
>> We provide LTS so it is not possible for everyone. It would also not
>> catch the API break in the i-build.
>>
>
> API is deprecated for at least 2 years before being removed so if a
> project has deprecations free build with the 2 years old version it will
> work fine with the latest release.
>
>
>>
>> 1. The person that proposes the API change makes an impact analysis by
 searching all the Eclipse repositories, removal is abandoned if used > x%
 2. Removal of API is sent to the mailing list of the project that uses
 the API so that we can fix things in time, especially when the project is
 in maintenance mode.

>>>
>>> 1. and 2. are not realistic if we go that path why don't we add Spring
>>> Tools or JBoss Tools which are one of the widely used plugins out there.
>>> Why not add Pydev too? Requiring to subscribe to project list to notify is
>>> a bit too much for me. There is a reason we have cross-project list.
>>> Effectively this proposal is to never ever change anything and let Eclipse
>>> Platform collapse under its own weight where we keep shipping multiple ways
>>> to do things - each with its own oddities.
>>>
>>
>> Yes, we should add them as well. It is also about the thousands of
>> consumers that we don't know.
>>
>> And I really don't think that leaving three lines in Platform will cause
>> Eclipse to collapse under its own weight. Java has never removed a
>> deprecated method or an API class. AFAICT, they are fine :)
>>
>
> That ^^ is no longer true for Java too.
> https://www.oracle.com/java/technologies/javase/jdk-11-relnote.html#Removed
> and continues in newer versions.
>

I just can't resist sending this link here
https://www.eclipse.org/lists/cdt-dev/msg34634.html .
Java  and the overall software world are changing on an ever increasing
pace - no matter whether we accept it, like it or not. Thus LTS (the old
10+ years) is gone - no matter how hard it is tried it will become harder
and harder and admitting that can save us quite a lot of frustration. One
can look at what is the current "extended" support e.g. Firefox does it
roughly for a year. And we live in that reality - JVMs break API on 6
months, GTK will have more than a huge change very shortly (4.x), latest
MacOS requires changing the binaries produced due to new CPU architecture,
IE is being replaced by Chrome engine powered engine and so on and on. With
all that said - either projects start working on their deps to keep the
support for things for longer or it will be gone not because WE WANT to
remove it but because WE HAVE to in order to throw the next release out and
keep it working on the new versions of our dependencies.
P.S. Before anyone brings the paid vs rest developers conversation again I
want to make smth crystal clear - No one just pays anyone to work on
whatever he wants in whatever way he wants if you find such a place let me
know. With faster and faster ecosystem changes an official task (aka being
paid for) for some of us is "REDUCE MAINTENANCE COST" and getting the blame
for not going to the extend that someone would like to see it while moving
like a snake (compared to other projects with which you compete for
resources) definitely has a positive and thankful effect for spending "my
own time" (quotes on purpose) trying to keep things going in the least
disruptive way possible while still preserving people to work on the
"thing".
P.S. 2 I would love to be pointed to another RCP/IDE platform that takes
backward compatibility more seriously than Eclipse TLP!!!


>
>
>>
>> Cheers,
>>
>> Wim
>>
>> ___
>> platform-dev mailing list
>> platform-dev@eclipse.org
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/platform-dev
>>
>
>
> --
> Alexander Kurtakov
> Red Hat Eclipse Team
>


-- 
Alexander Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Recent API Removal breaks clients

2020-09-18 Thread Wim Jongman 
>
> Although I'm not against such a rule, I don't think it will really fix
> those cases.
> The reason why consumer code is broken is because it wasn't maintained
> properly for several years and left usage of deprecated APIs while better
> alternatives have existed and are well documented, so I don't see how
> adding a couple of months would make code that's unmaintained for years
> suddenly be better maintained.
>

If point 1 and 2 are implemented from my original post then point 3  is no
longer important. If not, I have a 99% of catching it in my i-builds IDE
early in the cycle. If it is in the last 6 weeks (and over the holiday)
that chance reduces.

We have to accept that some projects don't have the resources. Some
projects like windowbuilder do not have any features added for a long
time. *However,
windowbuilder is consistently in the marketplace download top10*.  So many
many users use it. It works great for them.

There are no releng resources but me. I do it because it is such a great
tool and because there are so many users.

*WindowBuilder could well be one of the unique selling points of the IDE*.
Intellij/ does have some half baked designer [1] but ours is much much
better. Imagine what all these people think when they upgrade to 2020-09.

Points one and two in my original mail were easily dismissed but let's look
at them again.

1. The person that proposes the API change makes an impact analysis by
searching all the Eclipse repositories, removal is abandoned if used > x%
2. Removal of API is sent to the mailing list of the project that uses the
API so that we can fix things in time, especially when the project is in
maintenance mode.

Point 1. If the deprecated API is in use by a lot of projects. Then we MUST
not remove it. We are hurting our own projects if we do. It should not be
hard to make a grep -r "method" > usage.txt
Point 2. It should also not be hard to make a grep -r "method" >
projects.txt and then parse this to a target mailing list, right? That
would save windowbuilder from future embarrassments. Github will send you a
mail if there are vulnerabilities in your project dependencies.

Ideally, it should be maintained by Eclipse FND releng staff.

Then there is the escape "*Backing out of the removal*" [2]

If Ed or any other person that maintains an important project, has good
arguments to not remove an API then we must be able to apply the "Backing
out or removal" process. The procedure here must be described better
because now it is the PMC or the component lead that can deny the request.
This process is not correct because the component leads are also on the
PMC.

If API was released, then it belongs to the users of the API just as much
as to the developers. The discussion on this list is very
developer-centric. As developers, we primarily care about clean code and we
want to wipe out our design mistakes. The users have different concerns


[1] https://www.youtube.com/watch?v=-SmNpKskfJc
[2] https://wiki.eclipse.org/Eclipse/API_Central/API_Removal_Process
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Recent API Removal breaks clients

2020-09-18 Thread Wim Jongman 
On Fri, Sep 18, 2020 at 10:48 AM Mickael Istria  wrote:

>
>
> On Fri, Sep 18, 2020 at 10:27 AM Wim Jongman 
> wrote:
>
>> Yes, we should add them as well. It is also about the thousands of
>> consumers that we don't know.
>>
>
> Consumers should follow the mailing-lists of projects they strongly rely
> on.
>

I am running with 1300 bundles from at least 100 different projects. It is
not humanly possible to be on every mailing list. I just have to cross my
fingers and hope for the best
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Recent API Removal breaks clients

2020-09-18 Thread Aleksandar Kurtakov 
On Fri, Sep 18, 2020 at 11:27 AM Wim Jongman  wrote:

>
> Should we not support older versions of Eclipse?
>>>
>>
>> There is 2 years notice period so I would say do not support versions
>> older than 2 years.
>>
>
> We provide LTS so it is not possible for everyone. It would also not catch
> the API break in the i-build.
>

API is deprecated for at least 2 years before being removed so if a project
has deprecations free build with the 2 years old version it will work fine
with the latest release.


>
> 1. The person that proposes the API change makes an impact analysis by
>>> searching all the Eclipse repositories, removal is abandoned if used > x%
>>> 2. Removal of API is sent to the mailing list of the project that uses
>>> the API so that we can fix things in time, especially when the project is
>>> in maintenance mode.
>>>
>>
>> 1. and 2. are not realistic if we go that path why don't we add Spring
>> Tools or JBoss Tools which are one of the widely used plugins out there.
>> Why not add Pydev too? Requiring to subscribe to project list to notify is
>> a bit too much for me. There is a reason we have cross-project list.
>> Effectively this proposal is to never ever change anything and let Eclipse
>> Platform collapse under its own weight where we keep shipping multiple ways
>> to do things - each with its own oddities.
>>
>
> Yes, we should add them as well. It is also about the thousands of
> consumers that we don't know.
>
> And I really don't think that leaving three lines in Platform will cause
> Eclipse to collapse under its own weight. Java has never removed a
> deprecated method or an API class. AFAICT, they are fine :)
>

That ^^ is no longer true for Java too.
https://www.oracle.com/java/technologies/javase/jdk-11-relnote.html#Removed
and continues in newer versions.


>
> Cheers,
>
> Wim
>
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
>


-- 
Alexander Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Recent API Removal breaks clients

2020-09-18 Thread Mickael Istria 
On Thu, Sep 17, 2020 at 9:06 PM Wim Jongman  wrote:

> 3. API's are only removed before M1. This gives us some more time to catch
> and fix.
>

Although I'm not against such a rule, I don't think it will really fix
those cases.
The reason why consumer code is broken is because it wasn't maintained
properly for several years and left usage of deprecated APIs while better
alternatives have existed and are well documented, so I don't see how
adding a couple of months would make code that's unmaintained for years
suddenly be better maintained.
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Recent API Removal breaks clients

2020-09-18 Thread Mickael Istria 
On Fri, Sep 18, 2020 at 10:27 AM Wim Jongman  wrote:

> Yes, we should add them as well. It is also about the thousands of
> consumers that we don't know.
>

Consumers should follow the mailing-lists of projects they strongly rely
on. The API changes are notified on the relevant mailing-lists, they are
also noted in the migration guide. People who rely strongly on X (Eclipse
Platform in that case) and don't follow the project activity nor contribute
enough to bring their trouble when the API is proposed for removal and thus
mitigate the removal just do it wrong.
It shouldn't be up to committers to pay more effort for adopters who don't
follow the project well enough...

And I really don't think that leaving three lines in Platform will cause
> Eclipse to collapse under its own weight. Java has never removed a
> deprecated method or an API class. AFAICT, they are fine :)
>

3 lines here, 3 lines there...; in the end, API removal sums up to
thousands of lines over years and really decreases maintenance effort for
the project itself, which is an important goal for the project
sustainability, unless all adopters bring more manpower to face the growth
of features while still maintaining undesired code.

For JFace Assert, the deprecation is now 7 years old, and the alternative
API to use has been available for 15 years.
For platform.getJobManager(), the deprecation is now 6 years old, and the
alternative API to use has been available for 15 years.
It just looks like consumers of those outdated APIs just don't maintain
their code property if they're still using it. It's not really Platform
that's too blame because it was documented, left as it for 6-7 years with
an alternative already existing for 8 more years.
So just update your code to use what was recommended for 6 years, and then
you'll have 15 years old backward compatibility and ? years forward
compatibility for these pieces of code.
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Recent API Removal breaks clients

2020-09-18 Thread Ed Merks 

Wim,

I empathize with these concerns.  To prevent such problems, EMF's builds 
and test against a great many target platforms:


  https://ci.eclipse.org/emf/job/all-target-platforms/

This job builds the latest source and runs all the tests against helios 
and higher.  This was of course a lot of work to implement and is 
significant work to maintain; EMF takes Long Term Support very seriously.


Every time yet another thing is deprecated I cringe.  I maintain warning 
free code so I notice!  And then the threat of removal always looms on 
the horizon.   So when IProgressMonitorWithBlocking was deprecated, I 
notice, and then I notice too that it's in EMF's API, so the threat of 
removal means that I must break APIs should that come to pass.  But I 
don't break EMF's APIs, and I don't want break EMF's APIs.  Do I have a 
choice?  Does my opinion matter?  Not so much.


In this case, when I point out that if I were to actually try to remove 
my uses, that I would break behavior because the platform as a whole has 
not altered the code to make implementing IProgressMonitorWithBlocking 
redundant, I'm told that will happen later in the next release cycle.


  https://bugs.eclipse.org/bugs/show_bug.cgi?id=552683#c25

I don't comprehend the 
deprecate-now-but-don't-do-anything-about-it-until-later reasoning and 
I'm super frustrated by the constant threat of breakage.  As a word of 
caution, if IProgressMonitorWithBlocking is removed, EMF's build will 
become the progress monitor that blocks it.  I will make my opinion matter.


While I'm ranting and making myself unpopular, I look at p2's bug list 
and see that it's never reduced.   Instead there are disruptive changes 
that I'd rather not see:


  https://bugs.eclipse.org/bugs/show_bug.cgi?id=566070
  https://bugs.eclipse.org/bugs/show_bug.cgi?id=567030

Does my opinion matter?  Not so much.  Unfortunately Oomph has many 
wickedly-evil dependencies p2 so, in some ways, lack of change there is 
good...


I'm not being paid to maintain EMF/XSD, Oomph (and the installer), and 
JustJ, but others are being paid and while it's most definitely none of 
my business, I'd so much rather see the time spent fixing bugs than on 
constant cleanup activities, especially the disruptive ones.  If I were 
to spend a lot of time on cleanup activities, I would try to eliminate 
the 20,000 warnings I see in my SDK workspace.


I apologize in advanced to those whose shorts get in a knot over these 
comments.  No offense is intended.  This is an issue of community 
perception and the broader community doesn't perceive the vibrant, 
active developer community we have on the platform; one that I'm very 
grateful to have and to be a part of.  The key take-away is that the 
community generally only perceives the end result.


For example, the community doesn't perceive the goodness from this:

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

But rather perceives the bug that it causes:

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

Every time we delete something (even if it's internal non-API), we will 
definitely break something and someone, sometimes even our own stuff.  
Typically the end user is the first one who notices that, after the 
release, and that user perceives this problem as "Eclipse".  Even at 
Eclipse, not every project downstream from the platform has a rich, 
active, vibrant community to maintain their code base and release 4 
times a year.  Many, if not most, rely on the stability and quality of 
the platform, and when things are deleted 4 times per year, at arbitrary 
points in the cycle, it's hard to keep up with the goodness.


Even the move to Java 11 has been super disruptive to our community; at 
least I assume so because it was super disruptive for me personally.   
Of course this move is totally justified and is arguably goodness, but 
how many things will be broken by the move to Java 11, like this:


https://www.eclipse.org/forums/index.php/mv/msg/1105256/1832430/#msg_1832430

Probably not so many because this is a corner case.

I definitely worked my assets off to ensure that the installer would run 
out-of-the-box for 2020-09 and would even install a JRE if the user 
doesn't have a Java 11 installation available because I'm well aware 
that the failure to do so would reflect poorly on "Eclipse".  And I take 
LTS very seriously.


Again, I apologize in advance for any offense taken.  None is intended.  
We all want "Eclipse" to be great and do what we do to help ensure 
that's the case.  I just feel that the various points of view involved 
could be more balanced if more of them would be considered relevant.


Regards,
Ed

On 18.09.2020 10:26, Wim Jongman wrote:


Should we not support older versions of Eclipse?


There is 2 years notice period so I would say do not support
versions older than 2 years.


We provide LTS so it is not possible for everyone. It would also not 
catch the API break in the i-build.

*
*

Re: [platform-dev] Recent API Removal breaks clients

2020-09-18 Thread Wim Jongman 
> Should we not support older versions of Eclipse?
>>
>
> There is 2 years notice period so I would say do not support versions
> older than 2 years.
>

We provide LTS so it is not possible for everyone. It would also not catch
the API break in the i-build.

1. The person that proposes the API change makes an impact analysis by
>> searching all the Eclipse repositories, removal is abandoned if used > x%
>> 2. Removal of API is sent to the mailing list of the project that uses
>> the API so that we can fix things in time, especially when the project is
>> in maintenance mode.
>>
>
> 1. and 2. are not realistic if we go that path why don't we add Spring
> Tools or JBoss Tools which are one of the widely used plugins out there.
> Why not add Pydev too? Requiring to subscribe to project list to notify is
> a bit too much for me. There is a reason we have cross-project list.
> Effectively this proposal is to never ever change anything and let Eclipse
> Platform collapse under its own weight where we keep shipping multiple ways
> to do things - each with its own oddities.
>

Yes, we should add them as well. It is also about the thousands of
consumers that we don't know.

And I really don't think that leaving three lines in Platform will cause
Eclipse to collapse under its own weight. Java has never removed a
deprecated method or an API class. AFAICT, they are fine :)

Cheers,

Wim
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Recent API Removal breaks clients

2020-09-17 Thread Aleksandar Kurtakov 
On Thu, Sep 17, 2020 at 10:06 PM Wim Jongman  wrote:

> Hi,
>
> jface.util.Assert was removed as well as platform.getJobManager.
>
> I love the cleanup but I hate the panic that this causes. I take care of
> WindowBuilder and Nebula releng. We do not build against the development
> version but against an older version. This is to protect us to not
> accidentally use a new API that is not compatible with the oldest Eclipse
> we support. This means that the build completes normally.
>
> Should we not support older versions of Eclipse?
>

There is 2 years notice period so I would say do not support versions older
than 2 years.


>
> So now we have the removal of jface.util.Assert which breaks
> WindowBuilder. I did not see it because I did not use WB after Assert was
> removed only six weeks ago (over the holidays). Now the reports flow in
> because people are upgrading and we are no longer compatible with the
> latest eclipse.
>
> *I suggest adding three things to the API removal process.*
>
> 1. The person that proposes the API change makes an impact analysis by
> searching all the Eclipse repositories, removal is abandoned if used > x%
> 2. Removal of API is sent to the mailing list of the project that uses the
> API so that we can fix things in time, especially when the project is in
> maintenance mode.
>

1. and 2. are not realistic if we go that path why don't we add Spring
Tools or JBoss Tools which are one of the widely used plugins out there.
Why not add Pydev too? Requiring to subscribe to project list to notify is
a bit too much for me. There is a reason we have cross-project list.
Effectively this proposal is to never ever change anything and let Eclipse
Platform collapse under its own weight where we keep shipping multiple ways
to do things - each with its own oddities.


> 3. API's are only removed before M1. This gives us some more time to catch
> and fix.
>

^ That one makes sense to me.


>
> Cheers,
>
> Wim
>
> * As an added bonus I now also have to deal with the removal of
> platform.getJobManager that break the IBM rational plugins that we use for
> our product. Now I have to chase IBM to fix something, I'd rather be
> fighting windmills.
>
>
>
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
>


-- 
Alexander Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

[platform-dev] Recent API Removal breaks clients

2020-09-17 Thread Wim Jongman 
Hi,

jface.util.Assert was removed as well as platform.getJobManager.

I love the cleanup but I hate the panic that this causes. I take care of
WindowBuilder and Nebula releng. We do not build against the development
version but against an older version. This is to protect us to not
accidentally use a new API that is not compatible with the oldest Eclipse
we support. This means that the build completes normally.

Should we not support older versions of Eclipse?

So now we have the removal of jface.util.Assert which breaks WindowBuilder.
I did not see it because I did not use WB after Assert was removed only six
weeks ago (over the holidays). Now the reports flow in because people are
upgrading and we are no longer compatible with the latest eclipse.

*I suggest adding three things to the API removal process.*

1. The person that proposes the API change makes an impact analysis by
searching all the Eclipse repositories, removal is abandoned if used > x%
2. Removal of API is sent to the mailing list of the project that uses the
API so that we can fix things in time, especially when the project is in
maintenance mode.
3. API's are only removed before M1. This gives us some more time to catch
and fix.

Cheers,

Wim

* As an added bonus I now also have to deal with the removal of
platform.getJobManager that break the IBM rational plugins that we use for
our product. Now I have to chase IBM to fix something, I'd rather be
fighting windmills.
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev