• Adapt to JENKINS-68249

      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-68251] Adapt to SVG icon removal from JENKINS-68249

          Alexander Brandes added a comment - - edited

          For tracking the affected plugins, would it work out if we link the PR that addresses the regression to this issue while adding TODOs and candidates for deprecation in a table overview right into the issue body?
          I've addressed this in a variety of plugins in the past and I feel like raising a new issue for every already fixed plugin seems a bit wasted.

          Alexander Brandes added a comment - - edited For tracking the affected plugins, would it work out if we link the PR that addresses the regression to this issue while adding TODOs and candidates for deprecation in a table overview right into the issue body? I've addressed this in a variety of plugins in the past and I feel like raising a new issue for every already fixed plugin seems a bit wasted.

          Basil Crow added a comment - - edited

          Jesse used a table in JEP-227 (see https://github.com/jenkinsci/jep/blob/master/jep/227/compatibility.adoc), which I think worked pretty well, but keeping it up-to-date with pull requests to jenkinsci/jep was a bit of a drag.

          I used a Jira epic with issues in JEP-233 (JENKINS-65988), which worked well for me, even if it was a bit laborious to file all the issues.

          The way we keep track of this doesn't matter so much. Even a Google spreadsheet could work. The point is to have a list somewhere, and to make sure that the plugins we still claim to support get updated prior to the next LTS, and that the plugins that aren't updated are ones we are intentionally deprecating rather than unintentionally losing track of.

          Basil Crow added a comment - - edited Jesse used a table in JEP-227 (see https://github.com/jenkinsci/jep/blob/master/jep/227/compatibility.adoc ), which I think worked pretty well, but keeping it up-to-date with pull requests to jenkinsci/jep was a bit of a drag. I used a Jira epic with issues in JEP-233 ( JENKINS-65988 ), which worked well for me, even if it was a bit laborious to file all the issues. The way we keep track of this doesn't matter so much. Even a Google spreadsheet could work. The point is to have a list somewhere , and to make sure that the plugins we still claim to support get updated prior to the next LTS, and that the plugins that aren't updated are ones we are intentionally deprecating rather than unintentionally losing track of.

          Alexander Brandes added a comment - - edited

          I've set up https://docs.google.com/spreadsheets/d/1PxlgT11_uDyTzPch8zWn3PDxLUIAab21ILmJ17zCzBk adding (almost) all of my past preparations. Feel free to request access and I'll add you (or everyone else who requests it) as maintainer.

          Alexander Brandes added a comment - - edited I've set up https://docs.google.com/spreadsheets/d/1PxlgT11_uDyTzPch8zWn3PDxLUIAab21ILmJ17zCzBk adding (almost) all of my past preparations. Feel free to request access and I'll add you (or everyone else who requests it) as maintainer.

          Basil Crow added a comment -

          This is a good start. Would it be possible to sort this by # of installations? Plugins with a large number of installations demand our attention more than plugins with a small or minuscule number of installations.

          Basil Crow added a comment - This is a good start. Would it be possible to sort this by # of installations? Plugins with a large number of installations demand our attention more than plugins with a small or minuscule number of installations.

          Alexander Brandes added a comment - - edited

          Added for the possible candidates, rejected ones can be added if they are moved to a different list.

          Alexander Brandes added a comment - - edited Added for the possible candidates, rejected ones can be added if they are moved to a different list.

          Basil Crow added a comment -

          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.

          Basil Crow added a comment - 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.

          Alexander Brandes added a comment - - edited

          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.

          Alexander Brandes added a comment - - edited 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.

          Ian Williams added a comment -

          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.

          Ian Williams added a comment - 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.

          Basil Crow added a comment -

          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.

          Basil Crow added a comment - 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.

            Unassigned Unassigned
            basil Basil Crow
            Votes:
            1 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated: