Hi Adam, Correct. N plays role of Z here if it we could control over it. But since we don't, we're also free from obligation to follow major/minor/patch requirements per semver, so it's just our own releases counter that signs that we changed something and our changes are based on upstream X.Y.Z version.
-- ,,,^..^,,, On Thu, Jul 9, 2015 at 7:22 PM, Adam Kocoloski <[email protected]> wrote: > 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 <[email protected]> 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! >> >> -- >> ,,,^..^,,, >> >
