couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <nsla...@apache.org>
Subject Re: [DISCUSS] Git workflow
Date Tue, 30 Apr 2013 13:57:32 GMT
On 30 April 2013 08:09, Dave Cottlehuber <dch@jsonified.com> wrote:

> On 30 April 2013 01:50, Noah Slater <nslater@apache.org> wrote:
> > As far as I understand it them, master becomes the place I cut release
> > candidates from. It is the place that is "ready to ship" at all points.
> > Which is a slight departure from how we have operated previous.
>
> I like this, especially if we can work on extending the CI work Jan +
> team have done to all platforms, we can be pretty sure stuff will
> "just work".


Yep. Ideally, we'll agree on a process to make sure tests are passing
*before* the merge. This is a separate discussion, however!


> > If you commit a feature to master with breaking changes, then all that
> > happens it that in the next feature release window, we bump the major
> point
> > version. Otherwise it's just a minor point version. Either way, the
> release
> > is just master, and all the things that have been merged to it since the
> > last feature release.
> >
> > Let's say I cut 1.4 from master. This is point "a". A few months roll by,
>
> I think we'd push a signed tag that represents 1.4, just as we do
> today. This tag is just like a branch head, in that it stays in our
> repos indefinitely.


Yep, sorry. I took that as a given.


> > 2) After the release is made. The release is cut from master, and then we
> > branch from the tree-ish of the tag. (Herp derp, just correct my Git-fu
> if
> > I am getting things mixed up. Assume I mean the most obvious thing I
> could
> > be trying to say.) We still have the problem that all changes on master
> > have to be copied over to 1.4.x, for as long as we don't introduce
> breaking
> > changes.
>
> I guess it needs to go here, and the branch will only have bugfixes
> incorporated. If it's done later, it will include additional
> non-breaking features from master, & this branch would be a defacto
> 1.5 right?
>

Bingo.

-- 
NS

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