On Tue, Apr 9, 2024 at 9:34 PM Basil Crow <m...@basilcrow.com> wrote:
> Daniel, I am not aware of any such examples. > Thanks for that confirmation. At this point I'm not entirely convinced JENKINS-69361 is real, and unless you know more than is present in Jira, we don't understand it well enough to act on it. Trying to reproduce it by manually dropping instance-identity 113 and bouncycastle-api 2.26 in an otherwise 2.346.x Jenkins home (reproduction instructions are unclear how this would otherwise work given its core dependency) and starting 2.361.1, it gets appropriately ignored by entering the first block and passing the version comparison: PluginManager#loadDetachedPlugins: Upgraded Jenkins from version 2.346.2 to version 2.361.1-SNAPSHOT. Loaded detached plugins (and dependencies): [] While updating to a newer Jenkins results in bundled plugins being updated to the bundled releases if what's installed is older, it's possible to downgrade plugins afterwards and have that remain, as long as the core version doesn't change (not entering https://github.com/jenkinsci/jenkins/blob/16a65758149f71de1fd61dd0d7aa1fa9c06cd8c3/core/src/main/java/hudson/PluginManager.java#L812-L818). That manual downgrade would need to happen on every bundled version bump though, which given the regularity of plugin releases would be practically every LTS bump (not to mention the lack of support for downgrading configuration). It used to be possible for users to "pin" versions of plugins, but that was dropped in or around 2.0 when we no longer installed bundled plugins by default, making it basically an offline fallback only (resulting in the current policy IIRC). https://groups.google.com/g/jenkinsci-dev/c/kRobm-cxFw8/m/6V66uhibAwAJ and related messages may shed some light on how we got here. OTOH you've applied the pre-emptive updates for a while, as you wrote, and I'm not aware of many (or any) complaints about being forced to update plugins. At this point, neither the reasons to implement the policy change nor the reason not to are very convincing to me. Wearing my security hat I'd prefer updating everything all the time. As an admin I'd be more hesitant, but for the rare cases a bundled plugin release causes problems, the existing ability to downgrade (and wait for maintainers to fix whatever is the blocker) seems like it might be just enough to move forward with this. I guess this amounts to +0.5. Re the test -- I'd skip it for future automatic PRs. When we only updated bundled dependencies to address security vulnerabilities, we needed a way to ensure any such PR was complete, as nothing else would increase these versions until the next PR updating bundled plugins due to vulnerabilities. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAMo7PtL%3DCqsbn1P8Rn4mYbA03ey8dSer106bUNOW5%3Db%2BnT_07A%40mail.gmail.com.
