Solving “failing Parent Pom upgrade from 4.51 to 4.52 build” cheatsheet

[Jean-Marc Meessen]

(cross post from community.jenkins.io)

If you are like me,

• wondering why your dependabot PR builds are suddenly failing,
• unsure of the full implications of the latest plugin parent pom upgrade,
• and fear to waste time solving a problem that others have already solved,
• don’t trust your memory when having several plugins to maintain.

Here are my notes on how to move ahead.

Background:
Easily overlooked, the bump of plugin from 4.51 to 4.52 has a breaking change. The plugin build toolchain now requires at least Java 11 and at least Jenkins 2.361.

Solution:

• Make sure to use the correct Jenkins baseline
• Disable builds with Java 8

Checklist:

In the plugin’s pom.xml,

• Update the parent.pom (in the <parent> section) to 4.52
• Change the Jenkins base version (<jenkins.version> property) to 2.361.4
• Make sure that 2.361.x BOM is used (<artifactId>bom-2.361.x</artifactId> and <version>1723.vcb_9fee52c9fc</version>)
• Make sure that the pom.xml doesn’t force a Java 1.8 compilation

Make sure that Jenkinsfile specifies builds with the supported JDKs. (Relying on unknown defaults can bite you.) Your Jenkinsfile should look like this:

buildPlugin(
   useContainerAgent: true,
   configurations: [
      [platform: 'linux', jdk: 17],
      [platform: 'windows', jdk: 11],
   ]
)

Note:
If you don’t find the above mentioned elements in the pom.xml of the plugin you maintain, it is probably up for some tidying and “modernization”. See the Improve a Plugin Tutorial for hints.

If you have doubts or this checklist doesn’t work for you, don’t hesitate to discuss the matter on the developer mailing list.

/- Jmm

[Verachten Bruno]

Thanks a lot for this cheatsheet Jean-Marc, that will help for sure plugin maintainers.
I've done a few ones this week with this checklist, and it worked for most of them.

--
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/CABLvyXxOFqBAA1FGJSPQqE-LQmwViTvdtVK%3DZtpw9JqwpqCPvA%40mail.gmail.com.

--

Bruno Verachten

[Ullrich Hafner]

Thanks for the checklist!

Easily overlooked, the bump of plugin from 4.51 to 4.52 has a breaking change. The plugin build toolchain now requires at least Java 11 and at least Jenkins 2.361.

I would suggest to always update the major version of our plugin-pom if we make breaking changes. This is the second time that we deliver incompatible changes with the same major version. 

[Basil Crow]

On Wed, Dec 14, 2022 at 12:37 PM Ullrich Hafner
<ullrich...@gmail.com> wrote:
>
> I would suggest to always update the major version of our plugin-pom if we make breaking changes. This is the second time that we deliver incompatible changes with the same major version.

Perhaps; we do not officially use semantic versioning or any other
scheme where breaking changes are tied to the version number, nor did
we bump the major version number of Jenkins core itself when making
the breaking change to require Java 11 or newer there (a decision made
after discussion on this mailing list). I could see both sides to this
one: while a new major version number would have been a more clear
signal to consumers that adaptations are needed, it also might have
implied a major feature release (which was not the case). The last
major version number bump in the plugin parent POM (4.0) was done by
James Nord, and that _was_ a major feature release.

[Ullrich Hafner]

I don’t think that you need to deliver new features when you increment the major version in an API (actually we delivered the new feature Java 11 with tons of changes) - at least semantic versioning does not require that. But they clearly define the following rule which makes sense for other version schemes as well: 1. increment the MAJOR version when you make incompatible API changes.

[Jesse Glick]

On Wed, Dec 14, 2022 at 4:10 PM Ullrich Hafner <ullrich...@gmail.com> wrote:

increment the MAJOR version when you make incompatible API changes

It is a nice theory, but in practice nearly any change could be incompatible when the “API” is defined with less than mathematical precision. 4.52 obviously was incompatible for many repositories, but 4.49 also had an incompatible change affecting some repositories, and 4.50 had three. Best to just treat the version as opaque, and if your Dependabot CI build breaks (or even if it does not), read the release notes.

[Mark Waite]

On Wednesday, December 14, 2022 at 2:45:36 PM UTC-7 Jesse Glick wrote:

On Wed, Dec 14, 2022 at 4:10 PM Ullrich Hafner wrote:

increment the MAJOR version when you make incompatible API changes

It is a nice theory, but in practice nearly any change could be incompatible when the “API” is defined with less than mathematical precision. 4.52 obviously was incompatible for many repositories, but 4.49 also had an incompatible change affecting some repositories, and 4.50 had three. Best to just treat the version as opaque, and if your Dependabot CI build breaks (or even if it does not), read the release notes.

To further support that notion, the change from 4.52 to 4.53 includes a change in Jetty API that resulted in a compilation failure in the GitLab plugin.  As far as I can tell, it is the only plugin repository using the affected API, but there was a Jetty API change that affected it in the transition from 4.52 to 4.53.

Mark Waite