I want to adopt trunk based development for an opensource product and but I am not sure how it can be applied to documentation and build system changes.
Feature flags does not help for things that are meant for humans like documentation. Take the scenario where I want to move from a shell script based build system to using CMake. This change would mean:
- Creating new CMake build files
- Updating the documentation on the build procedure.
- Removing the shell scripts.
Now if this change takes more than a few days and more than one commit, it is very possible the ‘master’ branch would have for sometime both CMake and shell scripts and incomplete documentation.
The reason that this is even a problem is because I want the ‘master’ branch to be clean not just for the CI software but also to the humans.
I do have some idea involving short-lived feature branches or just accepting the fact the for sometime the ‘master’ would look unclean, but I want to know if there is a better and a more standard way to do these kind of changes.
PS: Having short lived feature branches is an option, but changes to build system might longer than 2 days to complete, so that would violate the TBD philosophy.
2
Feature flags does not help for things that are meant for humans like documentation.
When it comes to human consumption, the equivalent of a feature flag would be a nice big fat comment informing the reader of the status of the feature.
When dealing with documentation of software features, the comment can just refer to the feature flag that enables the feature in the software.
When dealing with build scripts, the comment should refer to the still existing (and working) build scripts that were used previously and are still used by the CI server.