| Re: [platform-dev] API changes in SDK |
>>If only the correct baseline were automatically set... If only the correct baseline were automatically set... And all the preferences too. I wonder how we could possibly do that? It seems pointless to me to record all these important details in an email thread. Record them in a wiki, if you feel these are important details that are best captured by documentation. Or perhaps consider yet again that it might be better to record these details in a script that is automatically applied and is used by everyone so that no one needs to read wikis and/or email threads with excruciating, manual, monkey-work tasks. The assertion appears to be that apparently automation doesn't work for inexplicable (and certainly unexplained) reasons. But for goodness sake, we are tool developers, surely we can use tools for all this! The term Luddite comes to mind when I read a thread like this. On 09.05.2019 18:43, Vikas Chandra wrote:
In short, before submitting any gerrit patch, just keep the default workspace settings and run API tools analysis ( clean->build all) after setting the correct baseline. Ensure that none of the settings has been made more lenient (error changed to warning or ignore in project setting) in the project. There is always a quickfix - API tool filter which allows user to override the API tool error based on user's judgement/scenario. Common sense overrides everything :) Suggestions on what can be improved in API evolution/versioning would be good to have. However, if version guidelines is not followed, then it can cause confusion to the end users. If there is a suggestion for changing the default settings that helps in overall API evolution or any other suggestion, please file a bug. ( One such bug is already filed by Dani ! ) Regards, Vikas ------------------------------------------------------------------------ Eclipse PDE lead, IBM EGL D Block - Bangalore, India ------------------------------------------------------------------------  Andrey Loskutov ---05/09/2019 12:50:25 AM---Hi all, If you do *not* contribute or review contributions for Eclipse platformFrom: Andrey Loskutov <loskutov@xxxxxx> To: platform-dev@xxxxxxxxxxx Date: 05/09/2019 12:50 AM Subject: [platform-dev] API changes in SDK Sent by: platform-dev-bounces@xxxxxxxxxxx Hi all, If you do *not* contribute or review contributions for Eclipse platform SDK, stop reading this mail NOW! I wanted to remind you about some simple rules for Eclipse SDK development, which are mandatory for all committers. If the commit you want to merge contains an API change, *before* merge you should *always* load the patch into your IDE and run a clean build on related project. Before doing so you should also make sure API tooling is properly configured, you use right API baseline and preferences are properly set: Preferences -> Plug in Development -> [x] Workspace Plug-Ins override target platform plugins... Preferences -> Plug in Development -> [ ] Disable API builder (must be unset!) Preferences -> Plug in Development -> Target Platform is set to "Running Platform" and you are using a recent nightly SDK build. Preferences -> Plug in Development -> API Baselines -> [x] _latest_release_ (must be created manually and point to plain SDK installation of the last official SDK release). If after that you see API errors in the workspace, please consider to read the proposed solution, compare that with the information you can get at [1], [2] and [3] and apply appropriated fix (or "-1" on the Gerrit patch). There can be multiple possible API error fixes proposed by PDE, but only one can be the right one - unfortunately we still require the power of human brain to apply the *right* fix. Please also note: human and computer make mistakes. Nobody is perfect, API tooling too. In doubt, ask on the list, but do not start *decrement* bundle versions or blindly increment them (because this always fixes the error, however may introduce a bigger one). Basic rule is: during a development cycle (e.g. 4.12) we only increment one version segment *one time* according to the rules [1], [2] and [3]. Only in case of human errors we have to bump the same version segment twice (once the wrong version is built and *published* we can't simply revert it so we must increase again...). We never decrement versions if they were already published via official SDK build. Decision about *which* bundle version segment to change should be always based on [1], [2] and [3], not just on PDE "quick fix" proposals. In doubt - ask on the list. Sure this is all complicated, sure this makes our life not easier and sure this could be improved and fully automated. But as long as we don't have an absolutely perfect, fully automated process we *must* follow the rules above. There are also few places where you can help: - Setup and use API tooling in your SDK workspace. Do it NOW! - Improve API tooling by contributing to PDE. There are known bugs and there are known performance issues, but if nobody helps, they will stay forever. - Contribute more maven checks that do *more* API checks during Gerrit build. [1] https://wiki.eclipse.org/Version_Numbering [2] https://wiki.eclipse.org/Evolving_Java-based_APIs [3] https://wiki.eclipse.org/Evolving_Java-based_APIs_2 Regards, Andrey -- Kind regards, Andrey Loskutov https://www.eclipse.org/user/aloskutov --------------------------------------------- Спасение утопающих - дело рук самих утопающих --------------------------------------------- _______________________________________________ platform-dev mailing list platform-dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev _______________________________________________ platform-dev mailing list platform-dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev_______________________________________________ platform-dev mailing list platform-dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev |