📅 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>;
Christian Decker [ARCHIVE] /
npub1wt…gtuyn
2023-06-07 02:36:51
in reply to nevent1q…5y5t
Author Public Key
npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuynPublished at
2023-06-07 02:36:51Event JSON
{
"id": "727e02ac17a051a1f4ab341d534dd91a8228b70484ef3c1212cf3abc0b47eaab",
"pubkey": "72cd40332ec782dd0a7f63acb03e3b6fdafa6d91bd1b6125cd8b7117a1bb8057",
"created_at": 1686105411,
"kind": 1,
"tags": [
[
"e",
"584ae74b575c9742306f580d5f64feda74a51793a9300be5c13870247fc9a7f7",
"",
"root"
],
[
"e",
"1416677d2c3d0898f621a2d07f12d6126b2bd326b3e7938a1e9acdfa95556017",
"",
"reply"
],
[
"p",
"c86b2a2e41d61aaf7ab7198ba65cf5a35c015f3117a71eaba5e19bb537b20051"
]
],
"content": "📅 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",
"sig": "dd4527d743f02546c132532d522f49f087a5af38c45587205845d7239cbb4bb9dad093bd9e31a8206c6440310e9dce03e3ab6cad61e74beba433199628ae31da"
}