I have a library (npm package, LIB) which is used by the application code (APP). In a release of APP, multiple features are worked on parallely. Sometimes these features need support from LIB, so the changes need to happen there too and LIB used semvar.
When multiple features like F1 and F2 are being worked on in APP, LIB is released with let's say
x.y.1 for F1 and then
x.y.2 for F2. Problem is the features are being developed and tested in parallel and it's possible that F2 lands but F1 doesn't. In which case LIB's release
x.y.2 contains undesirable code of
Right now I solve this using two methods:
Optimistically release LIB, revert undesirable code and release
x.y.3which is basically
x.y.1. Issues with this approach are:
x.y.3is a new release and is probably needed to be tested again.
- Overhead of reverting versions.
Use dirty code from LIB's F1 and F2 branches before releasing, to test APP. Once one of the feature is ready to land, the version is released. Let's say F2 is ready to land, then
x.y.1of LIB is released with support for F2 just in time. Issues with this approach are:
- Overhead of releasing the dependency (LIB) versions just ahead of release of APP.
- Unversioned code using git branches is hard to manage and prone to bugs. We use something similar to
git flowand reverting features from release branch of LIB because F2 has to go makes for more errors as reverting can cause errors. Also, the testing stands invalidated as the new release branch will be (F1 + F2 - F1) while the tests were done on (F1 + F2).
Both of these solutions have issues. I want to know how to solve this scenario where parallel development meets sequential semvar and I realize that reverting features just before release is an issue and unusual practice.
Thanks in advance.