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

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

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

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

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

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

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

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

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

> 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

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

> 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

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

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

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

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

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

> 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

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

> 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

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

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

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

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

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

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. >>> >> >>

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

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

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

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

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

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

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

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

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

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,

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

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

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

> 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

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

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

[platform-dev] Recent API Removal breaks clients

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