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

Enhance the update center metadata format to allow listing multiple versions of plugins and core

    XMLWordPrintable

    Details

    • Type: New Feature
    • Status: Open (View Workflow)
    • Priority: Major
    • Resolution: Unresolved
    • Component/s: core
    • Labels:
      None
    • Similar Issues:

      Description

      Currently the update center metadata only permits listing one version of Jenkins core and one version of every plugin. It would be nice if we could advertise not just the latest version of Jenkins / each plugin but also some other versions within the metadata. For example currently the update center will list something like

      {
        "core":{
          "buildDate":"...",
          "name":"core",
          "sha1":"...",
          "url":"...",
          "version":"..."
        },
        "plugins":{
          "async-http-client":{
            "buildDate":"...",
            "dependencies":[...],
            "developers":[...],
            "excerpt":"...",
            "labels":["library"],
            "name":"async-http-client",
            "requiredCore":"1.424",
            "sha1":"...",
            "title":"...",
            "url":"...",
            "version":"1.7.8",
            "wiki":"..."
          },
          ...
        },
        ...
      }
      

      In order to retain backwards compatibility, it would likely be necessary to introduce the extension as child elements... but care needs to be taken in order to preserve the signature verification semantics... the general idea would be to extend to something like:

      {
        "core":{
          "buildDate":"...",
          "name":"core",
          "sha1":"...",
          "url":"...",
          "version":"1.571",
          "history":{
            "1.570":{
              "sha1":"...",
              "url":"..."
            },
            "1.569":{
              "sha1":"...",
              "url":"..."
            },
            ...
          }
        },
        "plugins":{
          "async-http-client":{
            "buildDate":"...",
            "dependencies":[...],
            "developers":[...],
            "excerpt":"...",
            "labels":["library"],
            "name":"async-http-client",
            "requiredCore":"1.424",
            "sha1":"...",
            "title":"...",
            "url":"...",
            "version":"1.7.8",
            "wiki":"...",
            "history":{
              "1.7.7":{
                "dependencies":[...],
                "requiredCore":"...",
                "sha1":"...",
                "url":"..."
              },
              "1.7.7":{
                "dependencies":[...],
                "requiredCore":"...",
                "sha1":"...",
                "url":"..."
              },
              ...
            }
          },
          ...
        },
        ...
      }
      

      Where each history entry would be keyed by the version and contain a map of values that are a delta from the main entry (so that if requiredCore is the same as the main entry we don't list it... obviously sha1 and url are always going to be different and some values such as developers, title, etc probably don't need to be provided in the history as it is reasonably safe to assume that the current version is what matters... but that is a decision for the system generating the metadata... the principle should be that the format lists the delta.

      The format change would enable a lot more flexibility in plugin installation strategies available within Jenkins... the risk is that the metadata format change may make it impossible for older versions of Jenkins to upgrade so great care is required when making the format change... perhaps the simplest way is to make Jenkins core support reading the new format first and then change to the new format once the number of Jenkins instances accessing the OSS update centers that report an older version of Jenkins falls below a specific threshold (i.e. 5%)

        Attachments

          Issue Links

            Activity

            Hide
            jglick Jesse Glick added a comment -

            I think compatibility can be addressed by just exposing the new format on a new URL. The current *.json is anyway confusing since it is actually JSONP, not JSON. We could produce a new URL convention with an expanded format, in actual JSON (which core can now consume since it has the option to download from the master rather than through the browser).

            Show
            jglick Jesse Glick added a comment - I think compatibility can be addressed by just exposing the new format on a new URL. The current *.json is anyway confusing since it is actually JSONP, not JSON. We could produce a new URL convention with an expanded format, in actual JSON (which core can now consume since it has the option to download from the master rather than through the browser).

              People

              Assignee:
              Unassigned Unassigned
              Reporter:
              stephenconnolly Stephen Connolly
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Dates

                Created:
                Updated: