Replies: 2 comments 4 replies
-
|
I am more on team one master only, and one branch per release or hotfix. So there will be main, multiple release/vX.Y, and multiple hotfix/vX.Y.Z. All pull requests will go to release or hotfix branches, and that branch will allways start and end with master. That is because I don't think we are going to work feature level. But I can work easily either way. |
Beta Was this translation helpful? Give feedback.
-
|
The background for my question was handling of semver, which we must keep. I haven't been working on projects which follow semver, so I'm kind of new to organization around this. Don't know, if having a |
Beta Was this translation helpful? Give feedback.
-
|
If we need to develop fixes for previous major releases, such as creating a 7.1.1 hotfix, having a develop branch can be useful to gather all new developments. This allows us to merge fixes and features into the latest release as well. However, I typically don't follow this approach. Once we move to v8.0.0, v7 stops receiving bug fixes, and any critical issues would result in deprecating that version. That said, libraries that occasionally introduce breaking changes should allow users to continue using previous releases, and those releases might still need hotfixes. To manage this, we can keep the latest v7 release until it's considered obsolete or out of support, without needing to delete it. FluentAssertions, for example, only used master, which always contained the latest developments, simplifying the process. But I am up to any idea. |
Beta Was this translation helpful? Give feedback.
-
|
Extreme example: the first feature which we implement would be breaking, how would we act?
Yes, somewhat hypothetical before having a first feature at all :) |
Beta Was this translation helpful? Give feedback.
-
|
You can go with either approach. In fact, I know of big projects that use both methods, so it’s more about personal preference and habit than a strict organizational rule. Here's how I would suggest handling it:
This process ensures that you have a clear separation between ongoing development for major versions and bug fixes or small improvements for older versions. Feature branches will exist on each developer's machine, and once features are ready, they can be merged into the respective release branches using PR. |
Beta Was this translation helpful? Give feedback.
-
|
I created a Milestone to organize issues for the 8.0.1 patch, but I just realized we haven't discussed this yet. I agree with @cbersch that we need to define our organization strategy. At this point, it’s clear that we’ll have new developments to implement, whether they’re simple bug fixes or ongoing alignment with FA development. I can delete the Milestone if this is not a good way to proceed. I did it because it's what I am used to do. |
Beta Was this translation helpful? Give feedback.
-
After we're done with the chore stuff:
For actual code changes: Are we going to work on a
developbranch, like Fluent Assertions used to work with? (https://github.com/AwesomeAssertions/AwesomeAssertions/blob/main/CONTRIBUTING.md?plain=1#L69)Beta Was this translation helpful? Give feedback.
All reactions