Splitting a plugin into a legacy and supported part

[Ullrich Hafner]

Hi,

I want to retire a lot of old and legacy code in the code-coverage-api plugin in order to simplify the development experience (e.g., there are duplicate classes and jelly views). It is difficult for new contributors to start development when they do not know which classes and views are actually still used. Since there might be still some users that use the old and deprecated steps I am wondering how to do that in the best way.

1) Move the old code to a new plugin with new plugin id. Make that new plugin a dependency of the code-coverage-api plugin. Benefits: Everything is out of sight, not-used dependencies can be moved as well. Clean restructuring of the plugin.
2) Move the old code to a different source folder. Maven does support that but I am not sure if our maven-hi plugin does. Benefits: no new plugin is required, but dependencies need to be shared for both parts of the code.
3) Move the old code to a maven sub module in a new folder. Maven does support that but I am not sure if the rest of our build infrastructure does.

Or is there even another option that I do not see?

My favorite is option 1), but that requires to create a new plugin in the jenkinsci organization.

Ulli

[Daniel Beck]

On Fri, Oct 13, 2023 at 8:38 AM Ullrich Hafner <ullrich...@gmail.com> wrote:

Or is there even another        option that I do not see?

Depending on the scope of the problem, deprecation and finally removal of the obsolete stuff you want to remove.

Use usage-in-plugins to identify callers and consider providing PRs with the necessary changes for the more popular ones (and consider how much you care about non-public plugins).

Specify hpi.compatibleSinceVersion in the pom to tell admins that the new release is incompatible with older ones, and write a useful changelog.

[Jesse Glick]

On Fri, Oct 13, 2023 at 2:38 AM Ullrich Hafner <ullrich...@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.).

[Ullrich Hafner]

Am 13.10.2023 um 15:02 schrieb 'Jesse Glick' via Jenkins Developers <jenkin...@googlegroups.com>:

On Fri, Oct 13, 2023 at 2:38 AM Ullrich Hafner <ullrich...@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!