| I am certainly not opposed to the possibility of a breaking change in something we are confident is rarely used if it makes Jenkins architecture significantly simpler. In this case the fully compatible change leads to an equally simple architecture for new installations, and the delivery steps are not all that difficult if you are used to doing this sort of thing and can get a HOSTING request approved (which you would need in either case). And since the hosted Git repository was the only option for libraries for a long time, I suspect there are still a number of users out there who might be unpleasantly surprised by a breaking change. The thread mentioned “startup overhead” but it is not clear to me what this was about—the SSHD server is disabled by default already, and the handful of extensions involved in serving libraries or other Git repositories via either HTTP or SSH should not be contributing that much to class loading time. By the way, to retain commit history (git blame etc.), you could try doing this by creating a clone (Git clone, not GH fork!) of workflow-cps-global-lib-plugin from which WorkflowLibRepository and related old code is deleted in a new commit; while in the original repo, the newer code is deleted in a new commit. On the other hand git-filter-repo is claimed to be far easier to work with than what we used to use for plugin splits and similar refactorings. |
