I have a project that looks like this:
SOME_MONOREPO, managed by lerna - package-a - package-b - depends on package-a, package-c - package-c - is currently private, so not published as npm package. When package-b builds, it accesses package-c directly via symlink. As we move forward, we'll transition this to published packages like package-a. ANOTHER_PROJECT - package-foo- depends on SOME_MONOREPO.package-a
Now, say I'm doing some work on package-a, this could be a major, minor or patch change.
There are a few possible development flows:
- The simplest: the work just occurs on package-a, I write tests for it, and then when ready version bump and push to master.
- I'm doing work on package-a, but also updating package-b to adapt to the breaking changes/use the new functionality. In this scenario version bump isn't strictly necessary to do the code, because lerna's symlinks will still let package-b access the package-a code.
- I'm also doing work on package-foo. In this case I need to be publishing to npm in order to access the code.
So, I'm thinking that nightly/unstable/prerelease builds are warranted here. That is - I build some functionality on package-a, build an unstable artefact, and then package-foo can use it, see if it's fit for purpose.
At some point though - a decision needs to be made whether this is a major, minor or patch update.
The question is - when should this happen? Does the developer, when making changes, decide on their first PR to develop each time what the version bump is? (And it not being a release PR, the CI automatically publishes it with the 'unstable' appendix, when it is release the unstable appendix is removed). What about if another developer is simultaneously working on the same package?
Is there a way to not think about version bumps until formal release?