[Q or Feature Request] Need to bump version separately from `shipit` - currently get double bump
- Dominant language
- TypeScript
- Stars
- 2.5k
- Forks
- 221
- PR merge metrics
- No merged PRs in 30d
Description
## **Is your feature request related to a problem? Please describe.**
It is a problem for me, perhaps I am missing something or perhaps this is a feature request.
I have been integrating `auto` into multiple libraries, both simple and monorepos and it has worked well with only minor setup. Now I'm trying to bring `auto` to a full stack CI process, and I am seeing a limitation.
In our full stack application monorepo, we build multiple images, integration test, release sourcemaps to sentry, etc in our CI process to determine if a release candidate is certified to be `released`. The version value is statically built into the docker images/codebase for traceability e.g. `APP_VERSION: 3.1.0`. Therefore, we must bump the version _prior_ to `build` and `shipit`.
We perform the upfront bump with KIND=`auto version` and the result fed into `lerna version $KIND` so that `auto`'s logic controls the semver bump. But, when `shipit` runs, it bumps again, resulting in a double bump. So what should be `3.0.18->3.1.0` ends up being `3.0.18->3.2.0`.
## **Describe the solution you'd like**
`shipit --skip-version-bump`
We want to run the typical shipit, but simply with a flag to omit the bump version process.
## **Describe alternatives you've considered**
We must have the deterministic version statically upfront, so I'm not sure we have other options other than to revert to our homegrown release management.
## **Additional context**
It may be important to know that in this use case, `auto version` up front is limited in value (versus shipit) and returns major/minor/patch etc, but if you want to release this code as a canary/next, `auto version` is insufficient in this two-phase scenario. That's not necessarily a problem in our case, because it is simply a go/no-go deployment to a production stack. BUT, if someone wants to use this two-phase system, they _may_ want a full version resolution upfront e.g. instead of `minor` they may want `3.1.0-canary-tnoed283`. This may mean that another command would be useful such as `auto version --fully-resolved`
I hope I'm simply missing a flag and that a two-part/separate bump+ship process is achievable as-is.
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.