The code components (fabric, mem3, rexi, etc) have their own version numbers (following semver). Because of the way this was merged, many historical tags (used by Cloudant during our regular release cycle) are missing as they would pull in the pre-ip-cleared versions of the modules.
I don’t see a problem with the documentation repo having its own version number, but matching it to the couchdb release has merit too. Right now, rebar.config points to the master branch of each repository but this is *not* how we’ll manage things going forward (it is convenient right now as we validate the merge). To make a reproducible build, we must point at tags instead. The development of an enhancement to fabric (for example) is comprised of two parts. The first is the change to fabric itself, starting in a feature branch then being merged to master (after review) . The second being a new tag off fabric’s master branch and an update to rebar.config to point to it. B. On 13 Jul 2014, at 12:47, Alexander Shorin <[email protected]> wrote: > Hi devs, > > The question I'd like to raise is about version policy for the > components which were extracted from main big couchdb.git repo into > own separate ones. How to track their version now? > > For instance, we have jquery-couch.git now - jquery client for CouchDB > which was actively used by Futon and now is left orphan for standalone > usage. It never had own release version and now I wonder which to > apply on it? > > The only reasonable idea comes to my mind is to sync it with CouchDB > releases. For instance, the latest CouchDB 1.x release is 1.6 - so > jquery-couch.js is. If there will happens 1.7 release, we'll bump > jquery-couch.js up to 1.7 even if there was no any changes for it. But > since CouchDB 2.x timeline it will use own version strategy. > > Another example of the same issue is couchdb-documentation. It version > was heavy depended from CouchDB release one, but continuous to be so > for 2.x timeline. > > -- > ,,,^..^,,,
