This is a draft pull request which explores ways to split the plugin to two ones. Promotion's Permission entities look to be a major showstopper on this way, but just in case.
Research summary: Promotion is unsolvable knot if we want to retain binary compatibility
- Permission engine in Jenkins relies on Permission Groups, which reference class explicitly. In order to retain Permissions Promotion class has to be in promotion API
- Promotion is also a persisted object on the disk. We could use XStream features to rename the class and move all run entries. It would split the class to two... somehow
- Promotion and PromotionProcess are a part of the API used by other plugins. Class Renaming will not help unless full interface is retained. It includes fields, and hence it has to be class inheritance. Hence we have to keep public abstract class PromotionProcess extends AbstractProject<PromotionProcess,Promotion> implements Saveable, Describable<PromotionProcess> in promotion API with class relocation
- AbstractClass#getBuildClass() }}requires an exact class. And this is the end of the story for us, because the template declares {{PromotionProcess, and hence splitting classes is not possible.
So it is not possible to retain binary compatibility and to avoid pbreaking changes, at least without sophisticated Jenkins core patches.
This is a draft pull request which explores ways to split the plugin to two ones. Promotion's Permission entities look to be a major showstopper on this way, but just in case.
Research summary: Promotion is unsolvable knot if we want to retain binary compatibility
So it is not possible to retain binary compatibility and to avoid pbreaking changes, at least without sophisticated Jenkins core patches.