On 08/08/17 9:49 , Richard Haselgrove wrote:
> Clearly they need to be in the codebase which is being prepped for
> release: but they also need to be in the core development line which
> will form the basis for the next round of development. And we don't want
> to allow new features to creep into the release branch untested.

Correct. As long as you use branches and/or atomic commits that's easy
to achieve. This is one of the very reasons why we strongly keep
advocating these concepts!

> In my inexperienced mind, the easiest way to achieve that seems to be to
> bugfix in master, develop in branches.

Sort of. A typical workflow could look like this:

- Create a fix branch based on the release branch affected
- Fix the bug
- Merge the fix branch into the release branch
- Merge the fix branch into the master branch

If the fix is a single commit one could, in principle, use
cherry-picking instead, but I highly recommend to use proper branches
for fixes as well. The reason being that you never know beforehand that
a single commit will be enough (ie. it itself might need a fix) and
unfortunately commits often aren't as atomic as they should be which
would preclude isolated cherry-picking.

Bottom line, this is all about isolation and avoiding error-prone
redundancy with high efficiency.

For more on this I suggest you have a look at GitFlow to get an even
more complete picture:


It's a rather sophisticated model but the motivations and building
blocks are always the same, so it helps to understand the various
aspects. We certainly don't have to implement all of that but it has its
benefits, including explicit tool support - because it's now widely


Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

boinc_dev mailing list
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Reply via email to