couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dirkjan Ochtman <dirk...@ochtman.nl>
Subject Re: [REQUEST] [REMINDER] Merge changes for CouchDB 1.3.1
Date Tue, 21 May 2013 20:10:35 GMT
On Tue, May 21, 2013 at 9:30 PM, Noah Slater <nslater@apache.org> wrote:
> The CHANGES entry for 1.3.1 is showing:
>
>     *Nothing*
>
> The NEWS entry for 1.3.1 is showing:
>
>     *Nothing*
>
> Please take the time to edit these files so that they reflect the existing
> changes on this branch.

Personally, I don't think that docs refactoring needs to be mentioned
in NEWS/CHANGES/changelog. Does anyone disagree?

> # Merging master into the release branch
>
> Because the 1.3.x branch is the most release branch, all changes on master
> should be merged into it before we do the release.

Huh? Don't you mean that the other way around?

> TODO: What Git command best shows this? "git log --pretty=oneline
> 1.3.x..master" produces lost of spurious results. Bob tells me this is
> because we've been doing a lot of cherry-picking. I really want to figure
> out how we can make this easier to do. Perhaps even something kludgy like a
> script that runs this, but greps out known commits that don't count.

In other projects, we used to keep release branches as a true subset
of the master branch. That way, you can just keep merging the release
branch into master branch periodically (for every batch of fixes you
push). Would that work for this?

> Thanks for your help. This is going to be rough the first time we do it.
> But these regular releases should be massively beneficial to the project,
> and we will get better at them with practice (and automation).

Yay, thanks for the hard work!

Cheers,

Dirkjan

Mime
View raw message