I guess we can revert (this commit and) the fixes not to bump the the dependency so users will have maven-plugin updates in LTS, but I would like to avoid that. We can always deliver critical fixes in maven-plugin 2.0.1. Trying to stay compatible with LTS base release can make contributing more tedious. Especially for maven plugin where lots of changes span across core and plugin.
Yeah we can always do a 2.0.1 with cherry-picked fixes, it is just a bit tedious, so it is less likely to happen, and fewer available fixes would likely be included if it did.
Perhaps actively developed plugins (I do not think this is at all specific to maven-plugin) would keep multiple branches, but to avoid confusion no master: one for each existing LTS line, e.g. lts-1.509 and lts-1.532, and one post-lts. When committing a change or submitting a PR you would pick the earliest branch whose baseline core version could accommodate your change. And the plugin maintainer would need to periodically (or at least before releases) merge earlier branches into later branches, closing branches once the corresponding LTS line goes dead. Then no cherry picking is ever needed. Unfortunately maven-release-plugin is not really aware of this kind of version scheme—unless you use a different major version for each branch, which gives the (generally) false impression that incompatible changes are involved.
You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.
We use optional third-party analytics cookies to understand how you use GitHub.com so we can build better products.
Learn more.
We use optional third-party analytics cookies to understand how you use GitHub.com so we can build better products.
You can always update your selection by clicking Cookie Preferences at the bottom of the page.
For more information, see our Privacy Statement.
Essential cookies
We use essential cookies to perform essential website functions, e.g. they're used to log you in.
Learn more
Always active
Analytics cookies
We use analytics cookies to understand how you use our websites so we can make them better, e.g. they're used to gather information about the pages you visit and how many clicks you need to accomplish a task.
Learn more
This comment has been minimized.
This will make new updates of the plugin unusable on the forthcoming LTS. Is it really necessary?
This comment has been minimized.
I guess we can revert (this commit and) the fixes not to bump the the dependency so users will have maven-plugin updates in LTS, but I would like to avoid that. We can always deliver critical fixes in maven-plugin 2.0.1. Trying to stay compatible with LTS base release can make contributing more tedious. Especially for maven plugin where lots of changes span across core and plugin.
This comment has been minimized.
Yeah we can always do a 2.0.1 with cherry-picked fixes, it is just a bit tedious, so it is less likely to happen, and fewer available fixes would likely be included if it did.
Perhaps actively developed plugins (I do not think this is at all specific to
maven-plugin) would keep multiple branches, but to avoid confusion nomaster: one for each existing LTS line, e.g.lts-1.509andlts-1.532, and onepost-lts. When committing a change or submitting a PR you would pick the earliest branch whose baseline core version could accommodate your change. And the plugin maintainer would need to periodically (or at least before releases) merge earlier branches into later branches, closing branches once the corresponding LTS line goes dead. Then no cherry picking is ever needed. Unfortunatelymaven-release-pluginis not really aware of this kind of version scheme—unless you use a different major version for each branch, which gives the (generally) false impression that incompatible changes are involved.This comment has been minimized.
Cf. JENKINS-20209, fix not available in LTS.
This comment has been minimized.
@jglick: https://github.com/jenkinsci/maven-plugin/tree/lts-1.532
I will release this tomorow as 2.0.1 unless you have any objections. It is master without the couple of commits that required version bump.
This comment has been minimized.
Sounds good, thanks.