Status: Open (View Workflow)
We have a responsibility to our users to perform due diligence when making breaking changes to the ecosystem. When making such changes, it is incumbent on us to enumerate the affected plugins and, for each one:
- If the plugin is actively maintained, ensure a pull request has been created and ensure the pull request is merged and released prior to shipping the LTS.
- If the plugin is not actively maintained, make a conscious decision to leave it behind, ideally also filing an update-center2 PR to formally mark the plugin as deprecated in the Update Center.
This process has been followed for many other transitions, including JEP-227 and JEP-233.
The presence of
JENKINS-68250, JENKINS-68022, JENKINS-67737, and JENKINS-67176 (two of which remain in the "Open", rather than "In Review" or "Resolved", state at the time of current writing) indicate that such due diligence was not fully performed at the time of integration of JENKINS-68249.
A systematic search should be done across sources and binaries for all currently supported (non-deprecated) plugins to see if they are affected by the changes introduced in
JENKINS-68249. This ticket should be used to track the process of ensuring that each affected plugin gets released prior to shipping the LTS or gets (explicitly) left behind by a conscious decision.
JENKINS-68812 Build now icon broken in delivery pipeline plugin after update to Jenkins LTS 2.346.1
JENKINS-68847 Icon broken in latest LTS
- is caused by
JENKINS-68249 Remove assets that have been replaced with SVG versions
- links to
To me, almost everything with more than ~10,000 installations is a blocker, unless it is already deprecated or has existing unresolved security vulnerabilities (like Build Pipeline). Role Strategy has 87,560 installations; Copy Artifact has 53,282 installations. I do not think we can leave behind 25% of the installed base in good conscience. Users can and will complain, and our reputation will suffer.
Even the range between 1,000 and 10,000 installations needs to be considered, at least on a case-by-case basis (as Oleg did for tables-to-divs). Many of these plugins are still used in legacy or enterprise scenarios, and this represents a significant portion of the installed base. Things like Bitbucket Server Integration with 5,985 installations are still actively maintained (the last commit was 10 days ago), so I think we should provide a pull request.
I agree, considering the ease but amount of plugins, this is rather a question of time than difficulty to file these PRs. I'll bump the existing ones tomorrow in regards of the upcoming LTS baseline selection, Oleg's role strategy plugin is currently the most used plugin on the list.
Plugins with existing security vulnerabilities should be highlighted and need special treatment, if we want to address these too.
If my times allows it, I'll look forward to propose a few PRs tomorrow.
When considering the number of installations, please keep in mind that is not truly reflective of the size of the user base and the impact it could have. It's quite evident from some of the questions I answer on StackOverflow, the user is running a single instance on their desktop or VM, building a single application or a running a single of a few pipelines.
On the other hand, I administer multiple Enterprise instances with thousands of users, building 100's (probably 1000+ ) separate applications, with thousands of jobs. We also have multiple OpenShift instances which have a pre-configured Docker image with Jenkins and plugins preinstalled). Are are probably another 1000+ projects there. I don't even know if they send metrics back to Jenkins (the dependencies are all internally proxied).
A good example was the tfs-plugin. Most of the users who complained about it being revoked (legitimate action) are Enterprise Admins supporting a large userbase with standalone instances.
Numbers should be considered in the context out the service provided. If if possible to automatically scan all and create the PR, then I'd recommend going that way. It's then up to the maintainers to act or the community to step up and maintain once they see the need. You are also more likely to get an Enterprise user to step up and maintain given the impact.
I have turned this into an epic and linked any other bugs relating to this migration to the epic. I have attached the svg-migration label to this epic, the issue that caused this epic (
JENKINS-68249), and all issues in the epic.
I have retained the regression label on this epic because it is accurate. It is accurate because
JENKINS-68249 was merged and released prior to updating consumers, which would have been the way to go about such a migration without causing a regression (and the way JEP-227 and JEP-233 were done).
I have removed the regression label from all issues in this epic, because seeing them on various Jira dashboards in addition to the main epic was getting too distracting. They are all instances of the same problem, so having this epic show up a single time in dashboards suffices.
Added for the possible candidates, rejected ones can be added if they are moved to a different list.