> Am 13.10.2023 um 15:02 schrieb 'Jesse Glick' via Jenkins Developers > <jenkinsci-dev@googlegroups.com>: > > On Fri, Oct 13, 2023 at 2:38 AM Ullrich Hafner <ullrich.haf...@gmail.com > <mailto: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? >
Yes exactly. Users tend to not change a running system if they do not need to. They can update their pipelines later when they want to make use of the new step and the new features. And this is something I want to support. >> 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. Yes, you are right. I thought I can remove the dependency in a couple of months when everybody made the transition but it makes sense to use the opposite direction. > > `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.). This is the way I also used for the warnings next generation plugin. I created a new plugin that was added as a dependency to the old and deprecated warnings plugin. It has the disadvantage that the new plugin has a new plugin ID and name. But I think the benefits are much bigger as you also mentioned in your example. Another advantage of your suggested approach is that I can remove the API suffix of the new plugin as it does not provide any extension points for other plugins anymore. That means no other old and deprecated plugins will depend on the new plugin. Thanks! -- 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/EDD77542-E9E4-4F58-ABCB-A8A97ACC0B61%40gmail.com.
