On 02/15/2013 08:15 AM, Stephen Connolly wrote:
@since 1.480.4 and @since 1.502 and the reality is you can only rely on it with
1.502+
True, although most users going forward would either be using 1.480.{4+} or
1.{502+}, not 1.481–1.501.
A related risk: if you use the 1.480.3 plugin parent POM you might (perhaps unintentionally) make your plugin rely on an API backported to 1.480.3 as part of a bug fix.
*.hpi!/META-INF/MANIFEST.MF#Jenkins-Version (and hence update-center.json#//requiredCore) will now say 1.480.3 and so Plugin Manager will display no warning if a 1.490
user tries to install it. I suppose we could introduce a comma-separated list of minimum versions that handles branches, but this seems too complex and violates semantic
versioning.
Of course it is best to avoid introducing APIs in micro releases to begin with, but Jenkins lacks a strong separation of interface from implementation so this is not
always straightforward. (For example just making some tidbit of data available to a Jelly view requires a new public method.) @Restricted(NoExternalUse.class) should
probably be mandated on cherry picks that include new public members except in the rare case that introducing a new API to plugins is an essential part of the fix.
At any rate, I like Chris’s suggestion of {JenkinsReleaseVersion} for pull requests (or other development prepared in branches). Would require a possibly minor addition
to the script Kohsuke uses to cut a release, rc.changelog.rb perhaps.
--
You received this message because you are subscribed to the Google Groups "Jenkins
Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
