• 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

          Basil Crow created issue -
          Basil Crow made changes -
          Link New: This issue is caused by JENKINS-68249 [ JENKINS-68249 ]
          Basil Crow made changes -
          Description Original: The presence of JENKINS-68250, JENKINS-68022, JENKINS-67737, and JENKINS-67176 (two of which remain open at the time of current writing) indicate that 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. If new issues are discovered, new tickets should be filed for each plugin. New: 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 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. If new issues are discovered, new tickets should be filed for each plugin.
          Basil Crow made changes -
          Description Original: 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 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. If new issues are discovered, new tickets should be filed for each plugin. New: 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|https://github.com/jenkins-infra/update-center2] to formally mark the plugin as deprecated in the Update Center.

          This process has been followed for many other transitions, including [JEP-227|https://github.com/jenkinsci/jep/blob/master/jep/227/README.adoc] and [JEP-233|https://github.com/jenkinsci/jep/blob/master/jep/233/README.adoc].

          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.

          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.

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

              Created:
              Updated: