On Fri, Oct 13, 2023 at 2:38 AM Ullrich Hafner <ullrich.haf...@gmail.com> wrote:
> there might be still some users that use the old and deprecated steps > Like, Pipeline steps? So you cannot confidently delete this code without potentially breaking user workflows? > Move the old code to a new plugin with new plugin id. Make that new plugin > a dependency of the code-coverage-api plugin. > I think this is backwards—then you are permanently locking the deprecated code into the dependency chain. `workflow-cps-global-lib-plugin` originally contained an in-Jenkins Git server that you could push Pipeline Groovy libraries to. Later we added an option to pull libraries from the SCM of your choice, and deprecated the original code, but it stuck around and was a maintenance burden. So finally we introduced `pipeline-groovy-lib-plugin` containing just the newer code (in the same package structure and everything), made `workflow-cps-global-lib` depend on `pipeline-groovy-lib`, and deprecated the whole `workflow-cps-global-lib` plugin. Thus existing servers with `workflow-cps-global-lib` installed would upgrade plugins, which would automatically install `pipeline-groovy-lib` as a dependency, but see no behavioral change. Admins could then at their leisure uninstall `workflow-cps-global-lib` assuming they were not in fact using the old Git server. New servers need never install `workflow-cps-global-lib` to begin with (no longer a dep of `workflow-aggregator` or otherwise offered in the setup wizard, etc.). -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr1%2B2s9Ry%2BTU8y8h5ANST%2BZLyA9SpZuGNwJAt5D8PDdHFA%40mail.gmail.com.