Generally speaking, package releases move forward linearly in their versioning over time. After releasing 0.1.2 of a package, we release 0.1.3 or 0.2.0 or maybe even 1.0.0, and so on. But occasionally, it becomes necessary to release an update to an older version of a package due to certain constraints, e.g. the older version only works with an older version of Kibana.

Consider an integration package, foo. Let's say two versions of foo have been released so far: 0.9.3 and 0.10.1. Here, "released" means that the package version has made it to the staging or production stages of the package registry.

Further, the package foo continues to be developed in the integrations repo. As it stands, the master branch of the integrations repo contains version 0.10.2 of the foo package.

Now lets say we want to make some changes based on the 0.9.3 version of the foo package, and want to release these as version 0.9.4.

What should be the process to make such changes?

Ideally this process would:

• be easy and daresay even intuitive to execute for package maintainers, and
• result in the 0.9.3 version of foo going through the same testing and release steps as any other package version.

Related: #681 (actual example of a package that fits the above use case)