Consider Release per Upstream Dependency Change

[sghill]

In order to minimize breaking changes from dependencies
And maximize time to be notified of deprecations
As a gradle-jpi-plugin user
I want to release more frequently with smaller dependency changes

The release of v0.38.0 saw the jpi plugin bump the jenkins-test-harness version from 2.31 to 2.60 (#133).
This ended up being a breaking change for the jira-trigger-plugin because htmlunit upgraded from 2.18 -> 2.36.0.
A method in htmlunit was deprecated in 2.21 by HtmlUnit/htmlunit@d1697e8. It was removed in 2.25 by HtmlUnit/htmlunit@0371df2. Unfortunately since 29 versions were upgraded at once, the entire deprecation cycle was missed.

Ideally we'll want to strike the right balance, avoiding two things:

1. Releasing too often, creating a situation where it's nearly impossible to keep up and requires constant maintenance
2. Releasing so infrequently entire deprecation cycles are missed regularly

[sghill]

I've been thinking about this problem and wanted to capture some ideas here.

Added Dependencies

The plugin adds these dependencies to the target project when applied:

• core: org.jenkins-ci.main:jenkins-core:${jenkinsPlugin.jenkinsVersion}
• war: org.jenkins-ci.main:jenkins-war:${jenkinsPlugin.jenkinsVersion}
• access-modifier: org.kohsuke:access-modifier-checker:1.21
• findbugs: com.google.code.findbugs:annotations:3.0.0 or findbugs:annotations:1.0.0
• groovy: org.codehaus.groovy:groovy-all
• javapoet: com.squareup:javapoet:1.13.0
• jcip-annotations: net.jcip:jcip-annotations:1.0
• junit: only if jenkinsPlugin.jenkinsVersion < 1.505
• localizer: org.jvnet.localizer:maven-localizer-plugin:1.24
• servlet-api: javax.servlet:javax.servlet-api:3.1.0 or javax.servlet:servlet-api:2.4
• sezpoz: net.java.sezpoz:sezpoz:1.13
• test-harness: org.jenkins-ci.main:jenkins-test-harness:2.60 or 2.0 or jenkinsPlugin.jenkinsVersion
• ui-samples-plugin: org.jenkins-ci.main:ui-samples-plugin:2.0 or jenkinsPlugin.jenkinsVersion

Categories

I've been thinking of our dependencies as falling into four main categories, ordered here by how easy they are to maintain.

1. Declared

Examples: jenkins-core and jenkins-war. By specifying jenkinsPlugin.jenkinsVersion, we use this version exactly to wire up these dependencies. If the versions are invalid, they fail with a missing dependency.

2. Derived

Example: groovy-all. Groovy is a transitive dependency of jenkins-core. If a user does nothing, they get the version that Jenkins runs with.

3. Latest

Example: javapoet. This is a library used to generate a test class. It isn't deployed anywhere and there is no relationship to Jenkins. It'd be nice to always be on latest.

Example: jenkins-test-harness. This receives fixes and enhancements on its own schedule. It should always be used at latest.

4. Aligned

Example: servlet-api. This is a provided dependency for jenkins-core that is required for better error messages in annotation processing (#177). The version must align with either the embedded jetty version.

Example: sezpoz. This is a dependency whose version we specify today, but would become derived if we started depending on the platform org.jenkins-ci.main:jenkins-bom. This would significantly improve ease of maintenance as the version numbers would simply disappear from the codebase. It would also open the door to generating additional tasks that run against different versions of jenkins-core.

jenkins-bom

There are two main problems to solve with introducing jenkins-bom as a platform dependency.

The first bom version is for 2.164.1 (lts; 2.195 weekly). We'll need to either explicitly stop supporting building Jenkins plugins that depend on core before this version, or generate and publish platforms for previous releases. It'd be helpful to know how many plugins today depend on a version later than or equal to 2.164.1.

The second problem is verifying that each bom version provides all the dependency constraints we need.

[sghill]

Choosing a Jenkins version recommends not going older than 4 minor LTS releases ago, because they're not supported by the update center. For example, if the current release is 2.332.3, the oldest supported version is 2.277.3 from 12 months earlier.

Given the realities of needing to stay up-to-date to address vulnerabilities, it seems reasonable to follow a similar rolling schedule for support in this plugin. This would mean dropping support for anything that pre-dates the bom.