Configurable versioning strategy for when a dependency is updated

[markandrus]

Is your feature request related to a problem? Please describe.

Currently, when a dependency is updated, we increment the patch version of any dependents; however, there are cases where incrementing the major version makes more sense. For example, if the dependency participates in the dependent's public API, a breaking change to the dependency may imply a breaking change to the dependent. There may be a similar argument for the minor version, too.

Concrete example

Imagine we have a logging library ("logging") and an HTTP client library ("http-client"). The HTTP client library defines a class like this:

// http-client
import Logger from 'logging'
export class HttpClient {
  readonly logger: Logger
  constructor (readonly logger?: Logger) {
    this.logger = logger ?? new Logger()
  }
}

Logger, from the "logging" library, participates in HttpClient's public API, because it is accessible via the logger property (questionable design — a bit contrived — but let's run with it).

Describe the solution you'd like

If I have "http-client" at version 1.0.0 with a dependency on "logging" at workspace:^ or workspace:*, and "logging" goes from 3.0.0 to 4.0.0, then I expect "http-client" is automatically bumped from 1.0.0 to 2.0.0.

Of course, there will still be cases where dependencies are completely internal, and so the patch-level increment is desirable. I will need a way to tell monodeploy what to do (assuming some complicated API-aware machinery is out of the question).

I'd like this handled automatically, so that contributors do not forget to do it.

Describe alternatives you've considered

Manage the versions manually. Maybe leverage something like API Extractor to detect breaking API changes?

[markandrus]

Here is another potential use case: imagine an esbuild-like package where there is

• one core workspace of native code, and
• multiple OS × arch-specific workspaces packaging up cross-compiled artifacts from the core workspace (for example, see here).

The OS × arch-specific workspaces are typically setup once and only contain instructions for cross-compiling the native code. The OS × arch-specific workspaces might specify a dev dependency on the core workspace in order to have access to the native code during compilation. Any change in the core workspace (major/minor/patch) should trigger re-builds and re-releases of all the OS × arch-specific workspaces at the same version as the core workspace.

[noahnu]

Monodeploy has been forked under a new name Monoweave. I've copied your issue over and will address it in the monoweave project.

monoweave/monoweave#83