View Source mix git_ops.release (Git Ops v2.6.3)
Updates project changelog, and any other configured release capabilities.
mix git_ops.releaseLogs an error for any commits that were not parseable.
In the case that the prior version was a pre-release and this one is not, the version is only updated via removing the pre-release identifier.
For more information on semantic versioning, including pre release and build identifiers, see the specification here: https://semver.org/
Switches:
--initial- Creates the first changelog, and sets the version to whatever the configured mix project's version is.--pre-release- Sets this release to be a pre release, using the configured string as the pre release identifier. This is a manual process, and results in an otherwise unchanged version. (Does not change the minor version). The version number will only change if a higher version number bump is required than what was originally changed in the creation of the RC. For instance, if patch was changed when creating the pre-release, and no fixes or features were added when requesting a new pre-release, then the version will not change. However, if the last pre-release had only a patch version bump, but a major change has since been added, the version will be changed accordingly.--rc- Overrides the presence of--pre-release, and manages an incrementing identifier as the prerelease. This will look like1.0.0-rc01.0.0-rc1and so forth. See the--pre-releaseflag for information on when the version will change for a pre-release. In the case that the version must change, the counter for the release candidate counter will be reset as well.--build- Sets the release build metadata. Build information has no semantic meaning to the version itself, and so is simply attached to the end and is to be used to describe the build conditions for that release. You might build the same version many times, and this can be used to denote that in whatever way you choose.--force-patch- In cases where this task is run, but the version should not change, this option will force the patch number to be incremented.--no-major- Forces major version changes to instead only result in minor version changes. This would be a common option for libraries that are still in 0.x.x phases where 1.0.0 should only happen at some specified milestones. After that, it is important to not resist a 2.x.x change just because it doesn't seem like it deserves it. Semantic versioning uses this major version change to communicate, and it should not be reserved.--dry-run- Allow users to run release process and view changes without committing and tagging--yes- Don't prompt for confirmation, just perform release. Useful for your CI run.--override- Provide an explicit version override