Recent API Removal breaks clients

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Recent API Removal breaks clients

Wim Jongman-2
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
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
Reply | Threaded
Open this post in threaded view
|

Re: Recent API Removal breaks clients

Aleksandar Kurtakov


On Thu, Sep 17, 2020 at 10:06 PM Wim Jongman <[hidden email]> 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
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev


--
Alexander Kurtakov
Red Hat Eclipse Team

_______________________________________________
platform-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
Reply | Threaded
Open this post in threaded view
|

Re: Recent API Removal breaks clients

Wim Jongman-2

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
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
Reply | Threaded
Open this post in threaded view
|

Re: Recent API Removal breaks clients

Ed Merks-2

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.

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
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev

_______________________________________________
platform-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
Reply | Threaded
Open this post in threaded view
|

Re: Recent API Removal breaks clients

Mickael Istria-5
In reply to this post by Wim Jongman-2


On Fri, Sep 18, 2020 at 10:27 AM Wim Jongman <[hidden email]> 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
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
Reply | Threaded
Open this post in threaded view
|

Re: Recent API Removal breaks clients

Mickael Istria-5
In reply to this post by Wim Jongman-2


On Thu, Sep 17, 2020 at 9:06 PM Wim Jongman <[hidden email]> 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
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
Reply | Threaded
Open this post in threaded view
|

Re: Recent API Removal breaks clients

Aleksandar Kurtakov
In reply to this post by Wim Jongman-2


On Fri, Sep 18, 2020 at 11:27 AM Wim Jongman <[hidden email]> 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
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev


--
Alexander Kurtakov
Red Hat Eclipse Team

_______________________________________________
platform-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
Reply | Threaded
Open this post in threaded view
|

Re: Recent API Removal breaks clients

Wim Jongman-2
In reply to this post by Mickael Istria-5


On Fri, Sep 18, 2020 at 10:48 AM Mickael Istria <[hidden email]> wrote:


On Fri, Sep 18, 2020 at 10:27 AM Wim Jongman <[hidden email]> 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
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
Reply | Threaded
Open this post in threaded view
|

Re: Recent API Removal breaks clients

Wim Jongman-2
In reply to this post by Mickael Istria-5
 
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


_______________________________________________
platform-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
Reply | Threaded
Open this post in threaded view
|

Re: Recent API Removal breaks clients

Aleksandar Kurtakov
In reply to this post by Aleksandar Kurtakov


On Fri, Sep 18, 2020 at 12:30 PM Aleksandar Kurtakov <[hidden email]> wrote:


On Fri, Sep 18, 2020 at 11:27 AM Wim Jongman <[hidden email]> 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
[hidden email]
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
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
Reply | Threaded
Open this post in threaded view
|

Re: Recent API Removal breaks clients

Wim Jongman-2
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 <[hidden email]> wrote:


On Fri, Sep 18, 2020 at 12:30 PM Aleksandar Kurtakov <[hidden email]> wrote:


On Fri, Sep 18, 2020 at 11:27 AM Wim Jongman <[hidden email]> 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
[hidden email]
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
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev

_______________________________________________
platform-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
Reply | Threaded
Open this post in threaded view
|

Re: Recent API Removal breaks clients

Jonah Graham
In reply to this post by Aleksandar Kurtakov
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 <[hidden email]> wrote:


On Fri, Sep 18, 2020 at 12:30 PM Aleksandar Kurtakov <[hidden email]> wrote:


On Fri, Sep 18, 2020 at 11:27 AM Wim Jongman <[hidden email]> 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
[hidden email]
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
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev

_______________________________________________
platform-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
Reply | Threaded
Open this post in threaded view
|

Re: Recent API Removal breaks clients

Daniel Megert
In reply to this post by Wim Jongman-2
Guys

A lot of people watch this list and are not interested in this discussion. Can you please move it to a bug report. Also, I suggest to back your statements with data/facts, e.g. links to specs, Eclipse API docs etc.

Thanks,
Dani



From:        Wim Jongman <[hidden email]>
To:        "Eclipse platform general developers list." <[hidden email]>
Date:        18.09.2020 16:59
Subject:        [EXTERNAL] Re: [platform-dev] Recent API Removal breaks clients
Sent by:        [hidden email]




Brothers, I think we all can see each other's position. Our API must be kept clean but...                                                                                                                                                                                      
This Message Is From an External Sender
This message came from outside your organization.


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 <[hidden email]> wrote:


On Fri, Sep 18, 2020 at 12:30 PM Aleksandar Kurtakov <[hidden email]> wrote:


On Fri, Sep 18, 2020 at 11:27 AM Wim Jongman <[hidden email]> 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#Removedand 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

[hidden email]
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

[hidden email]
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev_______________________________________________
platform-dev mailing list
[hidden email]
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev



_______________________________________________
platform-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
Reply | Threaded
Open this post in threaded view
|

Re: Recent API Removal breaks clients

Lars Vogel-2
In reply to this post by Jonah Graham
> 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 <[hidden email]> 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 <[hidden email]> wrote:
>>
>>
>>
>> On Fri, Sep 18, 2020 at 12:30 PM Aleksandar Kurtakov <[hidden email]> wrote:
>>>
>>>
>>>
>>> On Fri, Sep 18, 2020 at 11:27 AM Wim Jongman <[hidden email]> 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
>>>> [hidden email]
>>>> 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
>> [hidden email]
>> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
>
> _______________________________________________
> platform-dev mailing list
> [hidden email]
> To 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: [hidden email], Web: http://www.vogella.com
_______________________________________________
platform-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
Reply | Threaded
Open this post in threaded view
|

Re: Recent API Removal breaks clients

Wim Jongman-2
In reply to this post by Daniel Megert



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
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
Reply | Threaded
Open this post in threaded view
|

Re: Recent API Removal breaks clients

Peter Kriens-2
In reply to this post by Lars Vogel-2
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
>>>
>>>
>>>
>>> On Fri, Sep 18, 2020 at 12:30 PM Aleksandar Kurtakov <[hidden email]> wrote:
>>>>
>>>>
>>>>
>>>> On Fri, Sep 18, 2020 at 11:27 AM Wim Jongman <[hidden email]> 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
>>>>> [hidden email]
>>>>> 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
>>> [hidden email]
>>> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
>>
>> _______________________________________________
>> platform-dev mailing list
>> [hidden email]
>> To 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: [hidden email], Web: http://www.vogella.com
> _______________________________________________
> platform-dev mailing list
> [hidden email]
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev

_______________________________________________
platform-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
Reply | Threaded
Open this post in threaded view
|

Re: Recent API Removal breaks clients

Wim Jongman-2
In reply to this post by Mickael Istria-5
 

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
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
Reply | Threaded
Open this post in threaded view
|

Re: Recent API Removal breaks clients

Wim Jongman-2



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.



_______________________________________________
platform-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
Reply | Threaded
Open this post in threaded view
|

Re: Recent API Removal breaks clients

Peter Kriens-2
In reply to this post by Wim Jongman-2
On 19 Sep 2020, at 13:08, Wim Jongman <[hidden email]> 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
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
Reply | Threaded
Open this post in threaded view
|

Re: Recent API Removal breaks clients

Ed Merks-2
In reply to this post by Peter Kriens-2
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
>>>>
>>>>
>>>> On Fri, Sep 18, 2020 at 12:30 PM Aleksandar Kurtakov <[hidden email]> wrote:
>>>>>
>>>>>
>>>>> On Fri, Sep 18, 2020 at 11:27 AM Wim Jongman <[hidden email]> 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
>>>>>> [hidden email]
>>>>>> 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
>>>> [hidden email]
>>>> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
>>> _______________________________________________
>>> platform-dev mailing list
>>> [hidden email]
>>> To 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: [hidden email], Web: http://www.vogella.com
>> _______________________________________________
>> platform-dev mailing list
>> [hidden email]
>> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
> _______________________________________________
> platform-dev mailing list
> [hidden email]
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
_______________________________________________
platform-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
12