• Icon: Improvement Improvement
    • Resolution: Fixed
    • Icon: Major Major
    • core
    • Jenkins 2.6

      Found when launching a jnlp agent from command line:
      "java -jar slave.jar -jnlpUrl ..."

      The name of this jar should match agreed naming guidelines.

          [JENKINS-35451] Change name of "slave.jar" to "agent.jar"

          Liam Newman created issue -
          Liam Newman made changes -
          Link New: This issue is related to JENKINS-35449 [ JENKINS-35449 ]
          Liam Newman made changes -
          Link New: This issue is related to JENKINS-31095 [ JENKINS-31095 ]
          Liam Newman made changes -
          Link New: This issue is related to JENKINS-35452 [ JENKINS-35452 ]

          Oleg Nenashev added a comment -

          It's not so easy, because many automation flows download slave.jar, windows-slave.exe and other such files from Jenkins. We can only add new endpoints and fix UIs, but the previous entries must be retained

          Oleg Nenashev added a comment - It's not so easy, because many automation flows download slave.jar, windows-slave.exe and other such files from Jenkins. We can only add new endpoints and fix UIs, but the previous entries must be retained

          Liam Newman added a comment - - edited

          Is eternal backward compatibility a core requirement? Can we create a plan for phasing these out? Provide both for some time period and then remove the old.

          File names in particular heavily influence the terms people use when talking about the product and features. Keeping "slave" in the file names essentially defeats any effort to remove the term "slave" from association with our product. As part of this transition, we're seeing people add the term "agent" but not remove the term "slave" from descriptions. "I'm have a problem with my jenkins slave agent." To get people to drop "slave", I think we need to not show them "slave-blah" every time they start an agent.

          Liam Newman added a comment - - edited Is eternal backward compatibility a core requirement? Can we create a plan for phasing these out? Provide both for some time period and then remove the old. File names in particular heavily influence the terms people use when talking about the product and features. Keeping "slave" in the file names essentially defeats any effort to remove the term "slave" from association with our product. As part of this transition, we're seeing people add the term "agent" but not remove the term "slave" from descriptions. "I'm have a problem with my jenkins slave agent." To get people to drop "slave", I think we need to not show them "slave-blah" every time they start an agent.

          Oleg Nenashev added a comment -

          > Can we create a plan for phasing these out? Provide both for some time period and then remove the old.

          We cannot, because there is no API deprecation policy/engine.
          As a remoting maintainer, I'm strongly -1 on removing original links within any visible timeframe. Too much fixing efforts and regressions due to just a renaming

          Oleg Nenashev added a comment - > Can we create a plan for phasing these out? Provide both for some time period and then remove the old. We cannot, because there is no API deprecation policy/engine. As a remoting maintainer, I'm strongly -1 on removing original links within any visible timeframe. Too much fixing efforts and regressions due to just a renaming
          Liam Newman made changes -
          Priority Original: Minor [ 4 ] New: Major [ 3 ]

          Liam Newman added a comment -

          The originally agreement was that the term slave would be removed from the UI, but left in the APIs to avoid breaking compatibility both for plugins and customer tools/scripts.   The problem is that line of where the UI stops and the API begins is a somewhat fluid when your users are engineers.

          I understand that filenames and urls are effectively part of the API and so changing them is problematic and could be considered out of scope.   But filenames and urls are also part of the end-user experience (the UI) for every Jenkins user. And the files and urls related to adding an agent are some of the first and most commonly used.

          Liam Newman added a comment - The originally agreement was that the term slave would be removed from the UI, but left in the APIs to avoid breaking compatibility both for plugins and customer tools/scripts.   The problem is that line of where the UI stops and the API begins is a somewhat fluid when your users are engineers. I understand that filenames and urls are effectively part of the API and so changing them is problematic and could be considered out of scope.   But filenames and urls are also part of the end-user experience (the UI) for every Jenkins user. And the files and urls related to adding an agent are some of the first and most commonly used.
          Oleg Nenashev made changes -
          Issue Type Original: Bug [ 1 ] New: Improvement [ 4 ]

            Unassigned Unassigned
            bitwiseman Liam Newman
            Votes:
            0 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated:
              Resolved: