Mostly correct.
We worked very hard to tame the explosion of checkboxes for everyone’s pet scenario.
I don’t want to block people’s pet scenarios because they are important to them, but the 90% of users will not share those specific use-cases.
With extension plugins we let each Jenkins instance only install the extension plugins they actually need and consequently tame the UI configuration options presented to users. It cannot be a perfect taming as some instances may need different strategies for different groups of users... but it will be better than presenting a wall of checkboxes.
In addition, we can make the testing easier as the core plugin will test the extension point api against its contract which reduces the untested surface for the extension plugin. For example with the branch build strategy, branch-api has tests for all the functionality that a bbs could do (no bbs, a bbs that says build, a bbs that says don’t build) so when writing a bbs you just need to verify that it returns true/false for the appropriate conditions.
Finally, by defining a contract we reduce the plugin upgrade risk, as we can maintain the original well defined contract as we evolve.
The down-side is discovery of potential traits that could be installed... but I may have a solution for that... namely if we add a link to a wiki page that uses confluence tags/labels to list all the extension plugins that could be installed.
With small extension plugins, they should have very few dependencies, and hence can be installed without restart in the vast majority of cases... which lowers the barrier for the Admin-User, who is typically tasked with forging the path as to how to map Jenkins features to business requirements.
-Stephen