{"type":"rich","version":"1.0","author_name":"npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuyn","author_url":"https://nostr.ae/npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuyn","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2011-11-02\n🗒️ Summary of this message: Chris suggests locking version numbers to protocol version and using sub_version_num field for builds to avoid version bumping.\n📝 Original message:I don't really get what you want to achieve with this. The protocol will be\nslow down evolution (hopefully) soon, while the clients will continue\nreleasing at a similar rhythm. It took long enough to decouple the protocol\nversion from being bumped each client release, now doing the inverse\ncoupling makes no sense.\n\nRegards,\nChris\nOn Wed, Nov 2, 2011 at 10:23 PM, Amir Taaki \u003czgenjix at yahoo.com\u003e wrote:\n\n\u003e Hey,\n\u003e\n\u003e Can we lock the version numbers to be the protocol version (which changes\n\u003e rarely) and instead use the sub_version_num field + revision number for\n\u003e individual builds?\n\u003e\n\u003e Satoshi 0.4\n\u003e BitcoinJava 120311\n\u003e bitcoin-js 6\n\u003e\n\u003e Like so. Otherwise we will have version bumping insanity :)\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e RSA(R) Conference 2012\n\u003e Save $700 by Nov 18\n\u003e Register now\n\u003e http://p.sf.net/sfu/rsa-sfdev2dev1\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111102/82bfa1e1/attachment.html\u003e"}