Branching Strategy #45
Replies: 3 comments
-
Just seeing this now, seems like a generally good strategy. One thing I wonder about, though, is how this strategy would work with both breaking and non-breaking changes in the master branch. An example:
How would we release the changes of commit C, if it has breaking changes (commit B) in its commit history? The first image in the linked article claims that we could branch 2.1.0 off of master at some point - but then we would need to make sure that no non-breaking change gets committed at any point before. The alternative would be to commit non-breaking changes both to the main and (major) release branch, but then we'd run into the same problems with non-breaking vs. bug-fixing changes, where one would increase the minor and the other the fix part of the version number. For real-world examples of breaking vs. non-breaking changes, look at issues:
|
Beta Was this translation helpful? Give feedback.
-
Thanks for your input on this. Eventually, I was thinking too big in this case (as often 🙂). To be honest, I am not really eager on maintaining a complex release branching strategy for this library. Maybe we should keep this really simple and make sure, we can focus on feature development instead of wasting time with merging / cherry picking commits between branches all the time. I have read about "trunk-based development" a bit (which seems to be the new standard for fast moving teams). It has some interesting approaches in it. I like it because it is simple. Here's an article about it: (there might be better ones): https://www.atlassian.com/continuous-delivery/continuous-integration/trunk-based-development Based on the article above, I would like to come up with a new approach:
This has some advantages for us:
But it has also advantages for library users:
Also, if we need to introduce a breaking change, given current version 2.2.3, we can just release a new version 3.0.0. The change log makes it clear what the breaking change is. But as the release 3.0.0 itself is a small release, adopting to 3.0.0 should not be too cumbersome for the dev. I think it is acceptable to have a policy like this. What do you say? |
Beta Was this translation helpful? Give feedback.
-
I assume that we will have many breaking changes in the near future, during our quest to become compatible with Mastodon API 4.0.0 (and further cleaning up the codebase in general), and only few of them later, as we find bugs or the Mastodon API changes in incompatible ways. In order to not bump our major version too often, maybe we can find a way to consolidate at least a good amount of these changes for a |
Beta Was this translation helpful? Give feedback.
-
I was thinking about a potential branching strategy for this library, given the situation, that there will be multiple releases pushed to the artifact repository (e.g. Maven Central) at the same time. Applying a branching strategy as described below would give us the freedom to implement bugfixes on earlier releases, without affecting the current development on the next version.
https://www.bitsnbites.eu/a-stable-mainline-branching-model-for-git/
Any feedback on this?
Beta Was this translation helpful? Give feedback.
All reactions