couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <nsla...@apache.org>
Subject Re: [REQUEST] [REMINDER] Merge changes for CouchDB 1.3.1
Date Tue, 21 May 2013 20:49:19 GMT
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.

On Tuesday, 21 May 2013, Dirkjan Ochtman wrote:

> On Tue, May 21, 2013 at 9:30 PM, Noah Slater <nslater@apache.org<javascript:;>>
> 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
>


-- 
NS

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