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?
Adam > On Jul 9, 2015, at 12:01 PM, Alexander Shorin <kxe...@gmail.com> 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! > > -- > ,,,^..^,,, >
