Hi, Alec See my additional comments.
On Thu, Oct 19, 2017 at 10:06 PM Alec Hothan (ahothan) <[email protected]> wrote: > Hi Yujun, > > > > The stable branch is created a few weeks before the release data and a lot > can happen in a few weeks. It could be lots of small commits related to > docs, lots of trivial fixes. The point I wanted to make is that you do not > want to see all these small detail commits on your release branch and hence > the notion of having a “clean” release branch devoid of detailed small > commits that do not need to be tracked at that level of branch. > > Say you have 20 commits to fix docs or 20 trivial fixes in code in the > week before release, will you want to have 20 commits on stable branch or > one? > One by one, since this is the history of amending the stable branch, we should keep it as it is. If we don't want to see trivial fixes, the right way could be squash them *BEFORE* submitting to master branch. > This is a case where a merge makes sense rather than cherry picking each > of them. > Normally, when we created stable branch, the master branch is mainly used for new feature development of next release. It may not be a good idea to merge them to stable branch. That's why we use cherry-pick to select only the bug fix and document amending. And this can not be done with merge. > Another case where merges make sense is when you deliver 5.1.0 with > possibly lots of new enhancements to 5.0, it makes sense to merge rather > than cherry pick lots of commits. > This also confuses me a lot, since the release date for 5.1.0 and 5.2.0 is overlapped with 6.0.0 development cycle. Normally I would add *NOTHING* new in 5.1.0 or 5.2.0 except for bug fixes. All new features goes into 6.0.0. This may save you from cherry-picking a bundle of commits and separate feature development from bug fixing. My another 2 cents. -- Yujun Zhang
_______________________________________________ opnfv-tech-discuss mailing list [email protected] https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
