I’m currently switching a plugin to JEP-229 automated releases, and need to decide on a versioning strategy for it. The plugin does not wrap a versioned component, so its version number is not meaningful. Due to the always-use-latest nature of Jenkins plugins, the only thing that needs to be conveyed to Jenkins users through versioning is whether the next plugin update is compatible or not.
I see two approaches for this…
In this approach, breaking changes are signified by incrementing the
major version component. For example
1.adecdef456789 1.vabcdef456789 # no increment => compatible 2.aesf8989ase91 # major increment => breaking change
This has the advantage that whether you define plugins in plugins.txt (i.e. you’re a Jenkins Docker user) or you update through the Update Center, you can always visually see there’s been a major version bump.
In this approach the version number is fully automated, and we indicate a breaking change with the
hpi.compatibleSinceVersion annotation. For example
adecdef456789 efdcdef456789 # compatible vesf8989ase91 + <hpi.compatibleSinceVersion>vesf8989ase91</hpi.compatibleSinceVersion> # breaking change
Originally this was only used to indicate configuration format changes, but I’m informed that it is now used for any breaking change.
This has the advantage that you get the incompatibility warning message displayed in the Update Center. The problem, as @timja has pointed out, is that Jenkins Docker users don’t see this message at all. They only find out that there’s a breaking change when the plugin update is already installed and it’s too late.
For this approach to be viable, there must be a way to surface
hpi.compatibleSinceVersion warnings for Jenkins Docker users. If we can’t find a way to do this, I think we need to instead recommend that plugins with no meaningful version retain control of the
major component and indicate breaking changes that way.
So… any suggestions on which direction to go?