rich1.0npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuynhttps://nostr.ae/npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuynnjumphttps://nostr.ae📅 Original date posted:2011-11-02 🗒️ Summary of this message: Chris suggests locking version numbers to protocol version and using sub_version_num field for builds to avoid version bumping. 📝 Original message:I don't really get what you want to achieve with this. The protocol will be slow down evolution (hopefully) soon, while the clients will continue releasing at a similar rhythm. It took long enough to decouple the protocol version from being bumped each client release, now doing the inverse coupling makes no sense. Regards, Chris On Wed, Nov 2, 2011 at 10:23 PM, Amir Taaki <zgenjix at yahoo.com> wrote: > Hey, > > Can we lock the version numbers to be the protocol version (which changes > rarely) and instead use the sub_version_num field + revision number for > individual builds? > > Satoshi 0.4 > BitcoinJava 120311 > bitcoin-js 6 > > Like so. Otherwise we will have version bumping insanity :) > > > ------------------------------------------------------------------------------ > RSA(R) Conference 2012 > Save $700 by Nov 18 > Register now > http://p.sf.net/sfu/rsa-sfdev2dev1 > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111102/82bfa1e1/attachment.html>