ignore recommendations for API plugins #5220
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
probot-autolabeler
bot
added
the
documentation
jtnord
commented
Jun 13, 2022
content/doc/developer/plugin-development/choosing-jenkins-baseline.adoc
Outdated
Show resolved
Hide resolved
lemeurherve
changed the title
jtnord
force-pushed
the
patch-9
branch
3 times, most recently
from
d768545 to
1bff1ef
Compare
following these recommendations for API plugins would be wrong. The reasons provided in the original PRs for doing so are all completely moot with an API plugin, and would lock out of any older version getting API fixes - esp security related ones or at least make it much more effort than would be required to deliver it.
MarkEWaite
approved these changes
Jun 13, 2022
Contributor
There was a problem hiding this comment.
This makes sense to me. @jglick, @daniel-beck, and @basil does this make sense to you based on the discussion in #4876 ?
jtnord
commented
Jun 13, 2022
| When updating the core dependency, choose the link:/changelog-stable/[newest LTS version] that doesn't exclude a majority of your existing users (by requiring a newer Jenkins than they have). | ||
|
|
||
| NOTE: if you are packaging a pure API library (one that does not depend on Jenkins APIs) then you should ignore newer jenkins versions and pick an older LTS. | ||
| Something around 1 year old that does not have too many detached plugins makes a good choice and *PLACEHOLDER_OLDEST_LTS* would be a reasonable candidate. |
Contributor
Author
There was a problem hiding this comment.
Ideally the plugin manifest could contain an option which could prevent the older baseline from even considering detached plugins for these types of plugins, but that is for another day.
Contributor
There was a problem hiding this comment.
Contributor
I was not involved in #4876. |
jglick
reviewed
Jun 13, 2022
Contributor
jglick
left a comment
jglick
left a comment
There was a problem hiding this comment.
Generally reasonable advice, though I am not sure I would say it is universally applicable as sometimes newer Jenkins baselines have updates to bundled plugins or corrections to Maven metadata which simplify the task of packaging the external library.
| When updating the core dependency, choose the link:/changelog-stable/[newest LTS version] that doesn't exclude a majority of your existing users (by requiring a newer Jenkins than they have). | ||
|
|
||
| NOTE: if you are packaging a pure API library (one that does not depend on Jenkins APIs) then you should ignore newer jenkins versions and pick an older LTS. | ||
| Something around 1 year old that does not have too many detached plugins makes a good choice and *PLACEHOLDER_OLDEST_LTS* would be a reasonable candidate. |
Contributor
There was a problem hiding this comment.
content/doc/developer/plugin-development/choosing-jenkins-baseline.adoc
Outdated
Show resolved
Hide resolved
| When updating the core dependency, choose the link:/changelog-stable/[newest LTS version] that doesn't exclude a majority of your existing users (by requiring a newer Jenkins than they have). | ||
|
|
||
| NOTE: if you are packaging a pure API library (one that does not depend on Jenkins APIs) then you should ignore newer jenkins versions and pick an older LTS. | ||
| Something around 1 year old that does not have too many detached plugins makes a good choice and *PLACEHOLDER_OLDEST_LTS* would be a reasonable candidate. |
Contributor
There was a problem hiding this comment.
Co-authored-by: Jesse Glick <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
following these recommendations for API plugins would be wrong. The reasons provided in the original PRs for doing so are
allmostly completely moot with an API plugin, and would lock out of any older version getting API fixes - esp security related ones or at least make it much more effort than would be required to deliver it.