How to not break dependant plugins and keep moving forward?

[Eric Citaire]

Hi everyone,

I recently adopted docker-java-api-plugin, which is a wrapper around docker-java, a Docker API Java client, used by other plugins like docker-plugin.

I released yesterday a 3.1.5 version, to make the corresponding version of docker-java available and benefit of new features and bug fixes. Unfortunately, the upgrade introduced some breaking changes (ie. moving classes), and it broke dependant plugins for users who installed the docker-java-api-plugin update (see https://github.com/jenkinsci/docker-plugin/issues/782).

Of course, the easy workaround is to downgrade docker-java-api-plugin to the previous version.

I really don't like breaking things and I was wondering if there were a way to avoid this and still be able to move forward. Dependant plugins are able to declare a minimum version of a dependency, but not a maximum version. Is there any way for me to declare a breaking change in the plugin manifest?

Thank you for your help.

Cheers,

Eric.

[Daniel Beck]

On Thu, Apr 2, 2020 at 3:35 PM Eric Citaire <eric.c...@gmail.com> wrote:

I really don't like breaking things and I was wondering if there were a way to avoid this and still be able to move forward. Dependant plugins are able to declare a minimum version of a dependency, but not a maximum version. Is there any way for me to declare a breaking change in the plugin manifest?

https://wiki.jenkins.io/display/JENKINS/Marking+a+new+plugin+version+as+incompatible+with+older+versions 

[Ullrich Hafner]

Am 02.04.2020 um 15:35 schrieb Eric Citaire <eric.c...@gmail.com>:

Hi everyone,

I recently adopted docker-java-api-plugin, which is a wrapper around docker-java, a Docker API Java client, used by other plugins like docker-plugin.

I released yesterday a 3.1.5 version, to make the corresponding version of docker-java available and benefit of new features and bug fixes.

Well, most Jenkins modules do not use semantic versioning (https://semver.org), but I think it is kind of common sense that you should not just increase the patch level when you introduce incompatible changes. Plugins that provide some kind of API should indicate changes in the API by increasing the major version, i.e. in your case creating a 4.0.0 release. 

Unfortunately, the upgrade introduced some breaking changes (ie. moving classes), and it broke dependant plugins for users who installed the docker-java-api-plugin update (see https://github.com/jenkinsci/docker-plugin/issues/782).

Of course, the easy workaround is to downgrade docker-java-api-plugin to the previous version.

I really don't like breaking things and I was wondering if there were a way to avoid this and still be able to move forward.

Moving classes in an API module is something that should be done only if you have no other chance to bring something forward. Is this the case in your plugin? Is there no way to introduce a new API and keep the old API alive? There are several alternatives available to improve an existing API. 

Dependant plugins are able to declare a minimum version of a dependency, but not a maximum version. Is there any way for me to declare a breaking change in the plugin manifest?

Maybe you need to explain your breaking changes in some more detail: do they affect the serialization format only, or do they break also the code of other plugins (i.e. a previously called method is not available anymore)? 

Thank you for your help.

Cheers,

Eric.

--
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-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/67447bbf-3202-477c-9082-732ee1cd65ad%40googlegroups.com.

[Eric Citaire]

Well, most Jenkins modules do not use semantic versioning (https://semver.org), but I think it is kind of common sense that you should not just increase the patch level when you introduce incompatible changes. Plugins that provide some kind of API should indicate changes in the API by increasing the major version, i.e. in your case creating a 4.0.0 release.

 

Moving classes in an API module is something that should be done only if you have no other chance to bring something forward. Is this the case in your plugin? Is there no way to introduce a new API and keep the old API alive? There are several alternatives available to improve an existing API. 

The thing is, docker-java-api-plugin is just a wrapper. I'm not the maintainer of the underlying lib docker-java. If maintainers of docker-java don't conform to semver, I can't do anything about it.

[Eric Citaire]

Le jeudi 2 avril 2020 15:37:58 UTC+2, Daniel Beck a écrit :

On Thu, Apr 2, 2020 at 3:35 PM Eric Citaire <eric....@gmail.com> wrote:

I really don't like breaking things and I was wondering if there were a way to avoid this and still be able to move forward. Dependant plugins are able to declare a minimum version of a dependency, but not a maximum version. Is there any way for me to declare a breaking change in the plugin manifest?

https://wiki.jenkins.io/display/JENKINS/Marking+a+new+plugin+version+as+incompatible+with+older+versions 

Ok, I'll try this.

Question : is it Ok to re-upload the same release of a plugin for this kind of change or does it require a new release ?

[Daniel Beck]

On Thu, Apr 2, 2020 at 5:25 PM Eric Citaire <eric.c...@gmail.com> wrote:

is it Ok to re-upload the same release of a plugin for this kind of change or does it require a new release 

You cannot overwrite existing releases, so it will require a new release.