For me, history documents changes and intention. Trunk based development seems inherently incompatible to that.
Many small commits intertwining different concerns makes it practically impossible to grasp changes by concerns or change sets. Once an issue inevitably occurs you may be able to work on the current state, but you can’t check what was changed together and why. If it’s not obvious from the code base you won’t be able to quickly assess the context.
The idea or thesis that many changes would lead to more stability (always deployable) is baffling to me. Changes are what introduces new issues. Mixing and intertwining concerns and people unaware of other changes in close time proximity increases risk.
More commits also don’t mean CI is more stable. A merge request as a gate to CI success is what does. A failed build on trunk already failed and blocks others.
While I develop a solution I specifically don’t want it on main. It’s a messy process, that may be partially reverted. Once I found my approach I clean up / define history and explain the approach and changes.
I want to commit the messy process too, for reference of my changes and approaches, and to have stuff I split off and integrate later. None of that belongs into main before I’m confident in the approach and changes. Because it’s specifically not stable and should not be deployed.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programming@programming.dev
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person’s post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
Follow the programming.dev instance rules
Keep content related to programming in some way
If you’re posting long videos try to add in some form of tldr for those who don’t want to watch videos
For me, history documents changes and intention. Trunk based development seems inherently incompatible to that.
Many small commits intertwining different concerns makes it practically impossible to grasp changes by concerns or change sets. Once an issue inevitably occurs you may be able to work on the current state, but you can’t check what was changed together and why. If it’s not obvious from the code base you won’t be able to quickly assess the context.
The idea or thesis that many changes would lead to more stability (always deployable) is baffling to me. Changes are what introduces new issues. Mixing and intertwining concerns and people unaware of other changes in close time proximity increases risk.
More commits also don’t mean CI is more stable. A merge request as a gate to CI success is what does. A failed build on trunk already failed and blocks others.
While I develop a solution I specifically don’t want it on main. It’s a messy process, that may be partially reverted. Once I found my approach I clean up / define history and explain the approach and changes.
I want to commit the messy process too, for reference of my changes and approaches, and to have stuff I split off and integrate later. None of that belongs into main before I’m confident in the approach and changes. Because it’s specifically not stable and should not be deployed.