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.
This comment has been minimized.
jglick repliedNov 13, 2013
This will make new updates of the plugin unusable on the forthcoming LTS. Is it really necessary?
This comment has been minimized.
olivergondza repliedNov 13, 2013
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.
jglick repliedNov 13, 2013
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.
jglick repliedDec 31, 2013
Cf. JENKINS-20209, fix not available in LTS.
This comment has been minimized.
olivergondza repliedJan 3, 2014
@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.
jglick repliedJan 3, 2014
Sounds good, thanks.