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: http://nvie.com/posts/a-successful-git-branching-model 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 accepted. HTH, Oliver
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ boinc_dev mailing list boinc_dev@ssl.berkeley.edu https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
