Yes, we will tag the dependencies and update rebar.config to point to them.
That's how we do this at Cloudant. Rebar config is only pointing to master branches while we're getting all the things working. Sent from my iPhone > On 22 Jul 2014, at 07:50, Samuel Williams <[email protected]> > wrote: > > Is there some way to maintain versions e.g. like how Gemfile does it? > >> On 13/07/14 23:47, Alexander Shorin 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. >> >> -- >> ,,,^..^,,, >
