couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randall Leeds <randall.le...@gmail.com>
Subject Re: [REQUEST] [REMINDER] Merge changes for CouchDB 1.3.1
Date Wed, 22 May 2013 00:06:48 GMT
On Tue, May 21, 2013 at 1:49 PM, Noah Slater <nslater@apache.org> 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.

Mime
View raw message