couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <>
Subject Re: [REQUEST] [REMINDER] Merge changes for CouchDB 1.3.1
Date Wed, 22 May 2013 00:55:07 GMT
This is a little over my head. I'll wait to see what Bob things. (As he's
my Git helper. Hehe.)

Why would we ever commit a fix to 1.3.x and not to master? (Assuming 1.3.x
is the most recent release branch.) My understanding of release branches is
that we move things *to* them from other places, usually master.

I think my main point is that at the point I cut the release, the code at
the tip of 1.3.x and master should be identical. Are you thinking this too?

I'm not sure if our understanding differs in results, or differs in process.

On 22 May 2013 01:06, Randall Leeds <> wrote:

> On Tue, May 21, 2013 at 1:49 PM, Noah Slater <> wrote:
> > Docs changes are fine left out.
> >
> > Merges happen from master to the branch, not the other way around. I cut
> > the release from the branch, and tag from the branch.
> >
> > Because this is patch version of our latest release line, 1.3.x should
> have
> > all changes on master merged in before we release.
> I think Dirkjan may be right here. It may answer my question the other
> day about this.
> If we periodically merged release branches into master it would make
> maintaining NEWS and CHANGES easier.
> If we assume, for a moment, that master has its NEWS and CHANGES up to
> date at this point in time and then fixes have landed on 1.3.x, we can
> keep NEWS and CHANGES maintenance easy by merging 1.3.x to master
> periodically.
> First, we update the NEWS and CHANGES on 1.3.x.
>  > git log 1.3.0..1.3.x
> This is what you showed earlier in this conversation. At this point
> we'd want to switch to 1.3.x and update NEWS and CHANGES.
> But we want to ensure that these NEWS and CHANGES items also make it
> into master so that these files don't get out of sync.
> Let's start the merge.
>  > git merge --no-commit -Xours 1.3.x
> Now we have staged a merge of 1.3.x to master that makes no changes
> ("ours" strategy), but have not committed it.
>  > git show 1.3.x:NEWS
> Copy the 1.3.x NEWS and CHANGES into the 1.3.1 (unreleased) section of
> the files.
> Next, we look to see the new features that have landed on master since
> we last did this.
>  > git log --first-parent `git merge-base 1.3.x master`..master
> This gives us all the commits on master since 1.3.x and master
> diverged. Using --first-parent means we'll see the only the merge
> commits from feature branches. We'll also see any merges (of the kind
> I'm suggesting we create here) of other actively maintained branches,
> but it's still low noise, high signal command for listing new features
> introduced on master.
> Update the 1.4.0 sections in NEWS and CHANGES. Stage these files for
> commit.
>  > git add NEWS CHANGES
> Now we can commit our merge. The contents of master won't change at
> all except that the unreleased sections of NEWS and CHANGES will be
> up-to-date. Once the merge is complete, we'll be able to follow this
> procedure again in the future to update these files incrementally.
> Another nice thing is that if people follow this procedure after doing
> any backporting work no one has to de-duplicate the logs later.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message