Add contributing guidelines. #5092
Conversation
|
|
||
| Most pull requests should go to the master branch and the change will be | ||
| included in the next major/minor version release (e.g., 3.6.0 release). If you | ||
| need to include a bug fix in a patch release (e.g., 3.5.2), make sure it’s |
There was a problem hiding this comment.
This sounds fine to me but there is also an argument to be made that bug fixes should go in the oldest supported branch and then merged upward to master. man gitworkflows says this about it:
Always commit your fixes to the oldest supported branch that requires them. Then (periodically) merge the integration branches upwards into each other.
This gives a very controlled flow of fixes. If you notice that you have applied a fix to e.g. master that is also required in maint, you will need to cherry-pick it (using git-cherry-pick(1)) downwards. This will happen a few times and is nothing to worry about unless you do it very frequently.
I kind of like that approach because then we can merge release branches into master without getting duplicate commits caused by cherry-picks. But really the issue is so minor that I am OK with the cherry-pick approach if that is the convention we're using.
There was a problem hiding this comment.
Thanks, Adam. Since you have been doing most of the branch integrations/cherry-picks recently, I think you have more first-hand experience than me and it makes sense to follow your preference here. I'm merging this PR as-is but could you help send a PR to update it to the workflow you prefer?
No description provided.