Hmm. Apparently I have forgotten to commit patches to both trunk and flume-1.7 branches.
I remember a long time ago we instituted the process of committing to both the trunk and flume-1.7 branches. However, I don't know of a good reason to keep doing that. Unless anyone objects, I propose we switch to the following branching model: 1. Only push to trunk on commit (usually) 2. Only create a version branch when we are branching for release 3. Only commit to the branch when we are about to release or when we plan on releasing a patch release, such as 1.7.1, 1.7.2, etc. I've seen this approach work in other projects and I think it is the most intuitive development model. Thoughts? Mike PS: In the meantime, I will cherry-pick all of my recent commits to the flume-1.7 branch. I just don't think we should create a flume-1.8 branch once we release Flume 1.7.0 On Wed, Jul 13, 2016 at 2:51 AM, Attila Simon <[email protected]> wrote: > Hi, > > Apparently there is a flume-1.7 branch which a bit diverged from > trunk. Please correct me if I was wrong but it should normally be the > branch for the release itself not the actual ongoing dev work. > > Checking what is in there (and not in trunk) I found the following commits: > > FLUME-2366. Updating Versions in 1.6 branch > FLUME-2366: Removing -SNAPSHOT from 1.5 branch > Restore correct Asynchbase version > > After looking at these changes their effect is already in trunk. Also > there are ~22 commits which are only in trunk but not in flume-1.7 yet > so trunk is well ahead. I think we can safely say that trunk branch > supersedes flume-1.7 branch at the moment. > > @Community: Should flume-1.7 branch exist at the moment? Its > existence seems confusing. If it should exists how changes from trunk > should appear there? > > > Cheers, > Attila > > ps: command used for comparison: > comm -3 -2 <(git log --pretty=format:%s origin/flume-1.7 | sort) <(git > log --pretty=format:%s origin/trunk | sort) >
