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%)