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 01:22:47 GMT
On Tue, May 21, 2013 at 5:55 PM, Noah Slater <nslater@apache.org> wrote:
> 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?

No. Master will eventually become 1.4.0 and may introduce new
features. Following semver dictates that these new features not land
in 1.3.1. Therefore, there will be commits on master which are not on
1.3.x.

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

Process. I'm just trying to improve the process.

Fixes could still originate on master.

Here's a diagram. In this I show a feature branch landing on master
and a backport of it landing on 1.3.x, but if we follow the procedure
I'm suggesting I think it can even be easy to keep track of
cherry-picked backports.

https://friendpaste.com/2AW98kyY8gQck6W1CjpZLY

The fancy things here are
  * merge-base: to find the common ancestor
  * --no-commit: so NEWS and CHANGES can be reconciled atomically with
respect to what the git logs will say is unmerged
  * -Xours: so that we can merge release branches to master *without*
code changes, just to mark a point in history so that a future
merge-base will only show us what hasn't made it into NEWS and CHANGES
since we last did this.

I'm happy to explain further if it is not clear, but we should start a
separate thread if we go much further in this discussion.

For the present moment we should ensure that NEWS and CHANGES are
up-to-date on both 1.3.x and master in preparation for the 1.3.1
release and that any backports are done promptly.

I do think that this process will be easier in the future if we then
merge 1.3.x into to master. Doing this regularly reduces or eliminates
the need for anyone to sit and compare the release branch history and
the master history looking for what was backported and what wasn't. If
we merge the release branches to master any time we backport them and
record the NEWS and CHANGES since the last we did so there should
never be such duplicates when it comes time to release.

Mime
View raw message