couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <rnew...@apache.org>
Subject Re: [DISCUSS] Git workflow
Date Thu, 25 Apr 2013 21:35:12 GMT
I'll toss this in too: https://sandofsky.com/blog/git-workflow.html

In particular;

"If you treat your public history as pristine, fast-forward merges are
not only safe but preferable. They keep revision history linear and
easier to follow"

I think this also addresses Paul's objections to merge commits (well,
non-ff merge commits).

If we enhance the #1 proposal to include a final rebase against master
before merge, then master will be truly linear. That will make for
easier reading, easier backporting and will enable bisecting when
spelunking for regressions, etc.

B.




On 25 April 2013 22:11, Noah Slater <nslater@apache.org> wrote:
> Dale,
>
> Take a look at the proposed roadmap process and let me know what you think.
>
> http://wiki.apache.org/couchdb/Roadmap_Process
>
>
> On 25 April 2013 22:03, Dale Harvey <dale@arandomurl.com> wrote:
>
>> #1 is the procedure almost every project I have worked on follows, we do
>> actually have an integration branch at mozilla but that is purely due to
>> the sheer size of the codebase and volume of changes, I see no reason why
>> CouchDB shouldnt be permanently releasable or why a release would be
>> 'ongoing', it should just be cut at a point in time?
>>
>> I do question the value of having 4 active releases though
>>
>>
>> On 25 April 2013 21:51, Noah Slater <nslater@apache.org> wrote:
>>
>> > Thanks for kicking this off, Bob!
>> >
>> > Option 1 would require us to change how we think about master. If a
>> release
>> > is ongoing (which will almost certainly be the case, month over month)
>> then
>> > work is going to need to be merged when it is okayed by the release
>> > manager.
>> >
>> > In this scenario, to  we might want to consider some sort of integration
>> > branch, or "develop" branch that you can merge your feature branches back
>> > into, while master is being used for release prep.
>> >
>> > Option 2 sounds promising, because there is less risk that we're going to
>> > re-invent the wheel (badly). It might also make it easier to attract
>> > contributors if we're using a known model.
>> >
>> > I'm not a Git pro, so my contributions to this thread are going to be
>> more
>> > of the "what about X?" nature. I had a look at Gitflow, and I can't
>> readily
>> > see how maintenance branches would work.
>> >
>> > The author suggests that release branches are discarded once you make a
>> > release. But we need to account for the fact that at any one time, we
>> will
>> > have 4 active release branches. 1.0.x, 1.1.x, 1.2.x, and 1.3.x, for
>> > example. We need these to backport fixes, etc.
>> >
>> > Further reading:
>> >
>> > https://github.com/nvie/gitflow
>> >
>> > http://nvie.com/posts/a-successful-git-branching-model/
>> >
>> > http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/
>> >
>> >
>> >
>> http://stackoverflow.com/questions/2621610/what-git-branching-models-actually-work
>> >
>> > What are other projects using? Node, for example. Any other big projects
>> > that use Git. It might be a good idea to borrow from one of these
>> projects,
>> > especially if there is some established thing that is shared amongst lots
>> > of them. Sort of how we're using Tom Preston-Werner's semantic
>> versioning!
>> >
>> > Hoping somebody with more skin in the game (i.e. doing / or planning to
>> do
>> > a lot of coding) and more experience of Git (I only learn how to rebase
>> > recently) decides to run with this and come up with a proposal that we
>> can
>> > all vote on. Perfect opportunity for someone to do a bit of project
>> > leadership!
>> >
>> >
>> >
>> > On 25 April 2013 21:37, Robert Newson <rnewson@apache.org> wrote:
>> >
>> > > Hi,
>> > >
>> > > We need to agree on how we will use Git effectively to support our new
>> > > regular release cadence. The motivating questions are how we handle
>> > > branches during feature releases (a.b.0) and how we handle branches
>> > > for maintenance releases (a.b.c).
>> > >
>> > > I present two options to get this rolling but these are not the only
>> > > choices, please suggest your own if neither suit.
>> > >
>> > > 1.
>> > >
>> > > Master is always releasable. All work occurs on feature or fix
>> > > branches and is merged to master only after tests confirm that it
>> > > works.
>> > >
>> > > A feature release (of form a.b.0) is tagged directly on master. A
>> > > branch is made from that tag called a.b.x (where x is a literal x)
>> > >
>> > > A maintenance release of form (a.b.c) is made on the a.b.x branch and
>> > > almost always consists of backported or cherry-picked work from
>> > > master. It is anticipated that some novel work will occur on these
>> > > branches but only to fix bugs never to add features.
>> > >
>> > > 2.
>> > >
>> > > Use Gitflow.
>> > >
>> > > Other suggestions are welcome and feedback on these is very welcome.
>> > > Consider this urgent as we need to begin the 1.4.0 release.
>> > >
>> > >
>> > > B.
>> > >
>> >
>> >
>> >
>> > --
>> > NS
>> >
>>
>
>
>
> --
> NS

Mime
View raw message