|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Looks great.
That's the idea, yes. There are very few exceptions to this rule.
Generally, if the plugin can do everything you want with somewhat older core dependency, that's the way to go. Obviously, if you want to use newer APIs or need behavior fixes (e.g. there were several versions where automated tests were broken on Windows), those are reasons to go with newer core versions.
The downside of an older core dependency is that this is used for automated tests and hpi:run, so while testing the plugin, you're using an older version. (You could always switch to a newer core during development to see how the plugin looks and works then, but do testing and releases with the older dependency so it's available to more users.)
There's a report on stats.jenkins-ci.org that shows how many installations have version X or higher (i.e. if something was added in X, how many installations have it). It may help you decide which version to depend on. With 1.532.1, released 9 months ago, currently ~75% of installations could use your plugin, which seems reasonable.
http://stats.jenkins-ci.org/plugin-installation-trend/capabilities.json