couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Shorin <kxe...@gmail.com>
Subject [PROPOSAL] Workflow with forked repos
Date Thu, 09 Jul 2015 16:01:52 GMT
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!

--
,,,^..^,,,

Mime
View raw message