Recommend specific core versions for the dependency

[daniel-beck]

Alternative to / parts to be reused in #3630 by @uhafner.

I basically wrote this just to demonstrate that we're now able to get update site tier metadata to make more specific recommendations as mentioned in #3630 (comment). Then I added split-plugins.txt and now it's essentially a fully automated recommendation engine for core baselines.

I updated the text a bit to make sense "standalone" with the recommendations given, but the script parts could just as easily be integrated into #3630.

[MarkEWaite]

I like the technique very much! It fits nicely with the idea to use the knowledge from update center in the generation of the Windows download page so that we stop using the symoblic link to latest.

[timja]

Thanks! Great to have it automated

[uhafner]

Using explicit versions is a great help for everybody! Thanks. This makes #3630 obsolete.

[jglick]

Fine I suppose, though my inclination is still to say that this is all making things unnecessarily complicated and that the most straightforward policy is just to do new plugin development against a current LTS baseline. Whenever I have checked plugin installation statistics, there are not really many people who are updating the plugin yet are not updating core to at least current LTS (if not weeklies), so the actual impact of the dependency is probably not that big; and having old core dependencies causes real harm to the Jenkins ecosystem. IMHO.

[jglick]

Not sure I agree with this advice (the *.1 part). Better to be testing the plugin against a core version that users are actually likely to have installed than some obsolete version with subtly different behavior. As for weeklies published after the LTS baseline, well yes but the same problem applies to *.1 also.

[daniel-beck]

having old core dependencies causes real harm to the Jenkins ecosystem. IMHO.

Could you elaborate? The major reason I'm aware of is implied dependencies which this script takes care of. Most other reasons (outdated tooling and configuration etc.) seem obsolete since plugin parent POM 2.0 became independent of the core release.

FWIW I have an improvement over this PR prepared locally that I plan to submit as future enhancement to never recommend versions older than 36 weeks (i.e. generally recommend "previous" and "previous previous" LTS lines).

Whenever I have checked plugin installation statistics, there are not really many people who are updating the plugin yet are not updating core to at least current LTS (if not weeklies)

There are many maintainers for which stats are not useful as plugin releases are usually too infrequent, so it's more difficult to "prove" this relationship beyond a general statement on this page.

[jglick]

The major reason I'm aware of is implied dependencies

There are lots of miscellaneous stuff that is best kept up to date in plugin sources—newly deprecated APIs, changes to nullability annotations, deleted Messages, various behavioral changes that break unit tests, ad nauseam. A green build only against a two-year-old core means that basically any real change to the plugin that happens to require a newer core is first going to have go through a long list of cleanups that are by that point half-forgotten. A lot of times these are necessary for PCT as well. In my experience it is less of a hassle to do little frequent updates, Dependabot-style¹; and on occasion something like a plugin test failure actually forces the author of the original core change to reconsider it, which is better done sooner than later.

Many aspects of tooling are indeed independent as of plugin-pom 2.0.

never recommend versions older than 36 weeks

OK, that would be an improvement from my PoV.

it's more difficult to "prove" this relationship

Indeed.

---

¹Even though we cannot literally use Dependabot for this purpose yet—nor can jenkinsci/bom do that for you, since jenkins.version overrides its dependencyManagement.

[daniel-beck]

Submitted an alternative #3655 with more aggressive baseline recommendation in the case that there were no recent plugin splits from core.

[MarkEWaite]

Submitted an alternative #3655 with more aggressive baseline recommendation in the case that there were no recent plugin splits from core.

I'd like to give this 24 hours for further discussion, then I intend to merge #3655. I think it is the right approach. Plugin authors can certainly ignore the recommendations or follow their own preferences, but I think recommending 2.204 (LTS - 2) and 2.222 (LTS - 1) as the preferred baselines are well suited to the Jenkins project.

[MarkEWaite]

Closing this and merging #3655