couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Kocoloski <>
Subject Re: [PROPOSAL] Workflow with forked repos
Date Thu, 09 Jul 2015 16:22:54 GMT
Excellent, very well thought through. I think I understand that the `X.Y.Z-couchdb.N` tag is
incremented for every new *release* generated as a descendant of the nearest reachable upstream
X.Y.Z version, as opposed to every new *commit*. That is, if we introduce 3 commits after
merging with 2.12.2 from upstream our release tag is 2.12.2-couchdb.1, right?


> On Jul 9, 2015, at 12:01 PM, Alexander Shorin <> wrote:
> Hi devs,
> I was plan to sync our couchdb-jiffy fork up to the current master
> (upstream latest release 0.13.3, our fork is on 0.9 tag). Recent
> versions of jiffy contains a lot of useful improvements for scheduler,
> tests, Windows build.
> However, here I came to the problem: our master is different from
> upstream one, because we removed binary rebar from the repo. And
> actually it should be different after all since we would need to
> configure .travis for our needs and do other organization work which
> drifts us away from upstream.
> So here is what I came with help of Paul J. Davis thoughts:
> - Each fork repo should contain upstream branch which is in sync with
> upstream source repository;
> - When need knocks the door, we merge upstream into master, where our
> local changes happens;
> - If our changes are not CouchDB-specific, we should try to avoid
> commit the to master and try to push them through upstream (submit PR
> to upstream repository, get it merged, sync upstream branch in our
> repo, merge it to master).
> - When release time happens, we need to pin our masters to specific
> commit. Hashes are not much verbose, so better to use tags. But in the
> same time we cannot say that we use mochiweb-2.8.1 since our fork is
> too much different from upstream. That's not good situation, but it's
> real one. To avoid confusion, we need to tag it specifically. I
> propose X.Y.Z-couchdb.N schema where X, Y, Z are closest upstream
> release tag, couchdb is an release identifier and N is our own
> incremental version.
> Example:
> Our current mochiweb fork is references to 2.8.1 version. So we can
> tag it HEAD as 2.8.1-couchdb.0 (0 as we didn't count any previous
> fixes per release).
> Assume, we fix something else there for the new CouchDB release - then
> we tag master as 2.8.1-couchdb.1 and so on.
> If we sync it with upstream, then next tag will be 2.12.2-couchdb.0 -
> assuming that our local changes survived the merge.
> I think such scheme will bring a little bit order into our workflow
> with forks and help to easily distinguish upstream releases from our
> own.
> Thoughts? Critics? All welcome!
> --
> ,,,^..^,,,

View raw message