monodeploy
monodeploy copied to clipboard
tophat
Configurable versioning strategy for when a dependency is updated
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?
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.
