<properties>
<jenkins.version>2.303.1</jenkins.version>
</properties>Your plugin’s POM controls which version of Jenkins it is building/testing against.
You need to balance compatibility and features:
Keeping the Jenkins version your plugin builds against low will allow more users to install and use your plugin. In particular, the LTS Release Line is based on slightly older releases to provide a more stable experience for conservative users.
Building against recent Jenkins versions allows you to use recently added core features and API from your plugin.
You will also use that newer version for mvn hpi:run, so it may be easier to test your plugin with newer Jenkins releases.
Do not use versions no longer supported by the update center, which is currently anything older than 2.272 for weekly releases, and 2.263.1 for LTS releases.
Prefer ".1" LTS releases over weekly versions and later releases within an LTS line for greater compatibility. LTS releases with the same baseline usually don’t have differences that would matter to plugin developers, and if they do, they may well behave differently on supposedly compatible weekly releases published shortly after the LTS baseline.
Prefer releases that no longer result in implied plugin dependencies. Sometimes Jenkins core features are moved into plugins, and any plugin with a dependency on an older core release will have an implied dependency on the new plugin. This makes plugin management more difficult for administrators, so core dependencies should ideally be chosen so that there are no, or few, implied dependencies. See split-plugins.txt for details. At this time, a dependency on Jenkins versions newer than 2.330 will not result in such implied dependencies.
There are statistics of core versions by plugin that can help you decide. These are updated monthly. When updating the core dependency, choose the newest LTS version that doesn’t exclude a majority of your existing users (by requiring a newer Jenkins than they have).