Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-68664

Clean code base: remove code marked as '@deprecated as of 1.286'

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Minor Minor
    • core
    • Jenkins 2.348

      I has try to improve some things in core (/computer pages ...) and find some 'old' code

      There are a lot of deprecated code blocks.
       
      @deprecated as of 1. --> will find 179 results in 87 files
      and 
      @deprecated as of 1.286 –> will find 30 results in 22 files.
       
      I propose to remove all code deprecated since 1.* , because on April 20, 2016 version 2 was released (google search). That means ever body has ~ 6 years to adapt plugins ... .
       
      When the community agree I can start with clean up. But please get feedback here which version shall I care.
       
      pro:
      This will helps to make the core code more:
      + readable
      + maintainable
      + faster build process
       
      contra:
      + some old plugins might no more works

          [JENKINS-68664] Clean code base: remove code marked as '@deprecated as of 1.286'

          Mark Waite added a comment -

          As far as I've seen, we intentionally do not remove deprecated methods from Jenkins API's. We retain compatibility by retaining deprecated APIs because that is a good way to retain users.

          There have been exceptions to that general behavior. However, they are usually preceded by a detailed analysis to confirm that Jenkins plugins have been reviewed for incompatibilities, pull requests have been submitted, and sufficient time has elapsed that the maintainer could have merged and released the pull request.

          This is a topic that is better suited to a developer mailing list discussion before you embark on the effort to remove deprecated APIs.

          Mark Waite added a comment - As far as I've seen, we intentionally do not remove deprecated methods from Jenkins API's. We retain compatibility by retaining deprecated APIs because that is a good way to retain users. There have been exceptions to that general behavior. However, they are usually preceded by a detailed analysis to confirm that Jenkins plugins have been reviewed for incompatibilities, pull requests have been submitted, and sufficient time has elapsed that the maintainer could have merged and released the pull request. This is a topic that is better suited to a developer mailing list discussion before you embark on the effort to remove deprecated APIs.

          Basil Crow added a comment -

          I concur with Mark overall, yet some deprecated APIs are so ancient that they really have no consumers in any plugins (with a search as described in https://github.com/jenkinsci/jep/blob/master/jep/227/README.adoc#searching-for-api-usages-in-binaries=). Most of the time these are harmless, but some of the time they have insidious effects: for example, consuming an unwanted dependency that could otherwise be removed (and increasing the risk that something new will also start consuming it). If the benefit is great enough and the risk is low enough (i.e., no consumers in OSS plugins or CloudBees CI as demonstrated via a search as described in https://github.com/jenkinsci/jep/blob/master/jep/227/README.adoc#searching-for-api-usages-in-binaries=) then I would support the removal of ancient cruft. But as Mark said, this has to be done very carefully, and in the cases where the benefit is small, it is best to err on the side of caution.

          Basil Crow added a comment - I concur with Mark overall, yet some deprecated APIs are so ancient that they really have no consumers in any plugins (with a search as described in https://github.com/jenkinsci/jep/blob/master/jep/227/README.adoc#searching-for-api-usages-in-binaries= ). Most of the time these are harmless, but some of the time they have insidious effects: for example, consuming an unwanted dependency that could otherwise be removed (and increasing the risk that something new will also start consuming it). If the benefit is great enough and the risk is low enough (i.e., no consumers in OSS plugins or CloudBees CI as demonstrated via a search as described in https://github.com/jenkinsci/jep/blob/master/jep/227/README.adoc#searching-for-api-usages-in-binaries= ) then I would support the removal of ancient cruft. But as Mark said, this has to be done very carefully, and in the cases where the benefit is small, it is best to err on the side of caution.

          markewaite  && basil thx for answers

           

          I know it is hard to remove old code because of compatibility with others (plugins, customer shared libs ...)

          We have always same issue in our product, like everybody . I know, this will be long doing process, but there are really benefits, when you has "clean" code base.

           

          Thx also for you link. It was helpful, because I found this tool https://github.com/jenkins-infra/usage-in-plugins .

          This is exact what I need https://assets.ci.jenkins.io/static-files/B8SRSImn48Np_Y5K82RWOr_o9nCJJZvAHlbTOY6q-dkxNjU0NzU3MzEzOTE3Ojk6YW5vbnltb3VzOmpvYi9JbmZyYS9qb2IvdXNhZ2UtaW4tcGx1Z2lucy9qb2IvbWFzdGVyL2xhc3RTdWNjZXNzZnVsQnVpbGQvYXJ0aWZhY3Q=/output/deprecated-and-unused.html

           

          When you agree I will:

          + adapt the tool usage-in-plugins to be possible

            + shown "long" is the code deprecated.

            + send mail notification to plugin maintainers about possible mismatch (when is running in jenkins-master and it is "new-used-deprecation" ....)

            + mark build as failed, when "new-used-deprecation" are found. So it will be necessary to clarify new deprecated code with others (potential dangerous, because some maintainers does not really answer, so it will be hard to mark so one code as deprecated)

            + shall be possible start it for groovy code, that the jenkins-administartos can check own shared-libraries

          + add some logger-severe message in the deprecate-unused parts like:

            'This function _FUNCTION_ is deprecated and  will be removed in future. See also https://issues.jenkins.io/browse/JENKINS-68664 for more information's'

          + add some logger-warning message in the deprecate-used parts like:

            'This function _FUNCTION_ is deprecated but can not be removed, because is still in use. Please inform maintainers about this. See also https://issues.jenkins.io/browse/JENKINS-68664 for more information's'

          + and / or add admin-monitor which can inform jenkins-administrators about that.

           

          So everybody can send us (post it in this ticket, or somewhere else (maybe new JEP will be better) the list of functions and we can merge it. Then can be "safely" removed after a bit time period (Ex: 3 months) 

           

           The steps described here, might be used in future, when some body marked the code as deprecated

           

          ps: I think this is "similar issue" https://issues.jenkins.io/browse/JENKINS-31035 therefore it can be linked.

          ps2: Pfuh. I see this will take a while and need much effort from my side (again)

           

          Martin Pokorny added a comment - markewaite   && basil thx for answers   I know it is hard to remove old code because of compatibility with others (plugins, customer shared libs ...) We have always same issue in our product, like everybody . I know, this will be long doing process, but there are really benefits, when you has "clean" code base.   Thx also for you link. It was helpful, because I found this tool https://github.com/jenkins-infra/usage-in-plugins . This is exact what I need https://assets.ci.jenkins.io/static-files/B8SRSImn48Np_Y5K82RWOr_o9nCJJZvAHlbTOY6q-dkxNjU0NzU3MzEzOTE3Ojk6YW5vbnltb3VzOmpvYi9JbmZyYS9qb2IvdXNhZ2UtaW4tcGx1Z2lucy9qb2IvbWFzdGVyL2xhc3RTdWNjZXNzZnVsQnVpbGQvYXJ0aWZhY3Q=/output/deprecated-and-unused.html   When you agree I will: + adapt the tool usage-in-plugins to be possible   + shown "long" is the code deprecated.   + send mail notification to plugin maintainers about possible mismatch (when is running in jenkins-master and it is "new-used-deprecation" ....)   + mark build as failed, when "new-used-deprecation" are found. So it will be necessary to clarify new deprecated code with others (potential dangerous, because some maintainers does not really answer, so it will be hard to mark so one code as deprecated)   + shall be possible start it for groovy code, that the jenkins-administartos can check own shared-libraries + add some logger-severe message in the deprecate-unused parts like:   'This function _ FUNCTION _ is deprecated and  will be removed in future. See also https://issues.jenkins.io/browse/JENKINS-68664 for more information's' + add some logger-warning message in the deprecate-used parts like:   'This function _ FUNCTION _ is deprecated but can not be removed, because is still in use. Please inform maintainers about this. See also https://issues.jenkins.io/browse/JENKINS-68664 for more information's' + and / or add admin-monitor which can inform jenkins-administrators about that.   So everybody can send us (post it in this ticket, or somewhere else (maybe new JEP will be better) the list of functions and we can merge it. Then can be "safely" removed after a bit time period (Ex: 3 months)     The steps described here, might be used in future, when some body marked the code as deprecated   ps: I think this is "similar issue" https://issues.jenkins.io/browse/JENKINS-31035 therefore it can be linked. ps2: Pfuh. I see this will take a while and need much effort from my side (again)  

          Basil Crow added a comment -

          If you're looking for a way to get involved with usage-in-plugins, fixing the regression introduced in https://github.com/jenkins-infra/usage-in-plugins/pull/21 and reintegrating that change would be a good place to start. Sorting results by popularity is another often-requested feature. If a plugin has less than a thousand users and hasn't seen commits or releases in years and is unlikely to be useful, that could be a good argument for deprecating the plugin. If an API is only used by deprecated plugins, it could be considered for removal, depending on how great the benefits were. In general the update center and plugin site could use some improvement about how plugins are marked for deprecation and how deprecation notices are displayed.

          Basil Crow added a comment - If you're looking for a way to get involved with usage-in-plugins , fixing the regression introduced in https://github.com/jenkins-infra/usage-in-plugins/pull/21 and reintegrating that change would be a good place to start. Sorting results by popularity is another often-requested feature. If a plugin has less than a thousand users and hasn't seen commits or releases in years and is unlikely to be useful, that could be a good argument for deprecating the plugin. If an API is only used by deprecated plugins, it could be considered for removal, depending on how great the benefits were. In general the update center and plugin site could use some improvement about how plugins are marked for deprecation and how deprecation notices are displayed.

          thx, i will look in the PR and try fix it. It can be good start.

          Martin Pokorny added a comment - thx, i will look in the PR and try fix it. It can be good start.

            Unassigned Unassigned
            mpokornyetm Martin Pokorny
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: