On 13 Jul 2014, at 13: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. How about syncing numbers now at the split but then have them evolve independently like the other repos/modules that BigCouch brings in? E.g. just skip the “empty bump” step from your proposal :) Best Jan -- > > 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. > > -- > ,,,^..^,,,
signature.asc
Description: Message signed with OpenPGP using GPGMail
