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