From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1RLiQb-0000Ov-7W for bitcoin-development@lists.sourceforge.net; Wed, 02 Nov 2011 21:32:57 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 74.125.82.53 as permitted sender) client-ip=74.125.82.53; envelope-from=decker.christian@gmail.com; helo=mail-ww0-f53.google.com; Received: from mail-ww0-f53.google.com ([74.125.82.53]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1RLiQa-0007Qn-8l for bitcoin-development@lists.sourceforge.net; Wed, 02 Nov 2011 21:32:57 +0000 Received: by wwg7 with SMTP id 7so845358wwg.10 for ; Wed, 02 Nov 2011 14:32:50 -0700 (PDT) Received: by 10.227.202.140 with SMTP id fe12mr7745799wbb.27.1320269570098; Wed, 02 Nov 2011 14:32:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.37.214 with HTTP; Wed, 2 Nov 2011 14:32:10 -0700 (PDT) In-Reply-To: <1320268981.72296.YahooMailNeo@web121003.mail.ne1.yahoo.com> References: <1320268981.72296.YahooMailNeo@web121003.mail.ne1.yahoo.com> From: Christian Decker Date: Wed, 2 Nov 2011 22:32:10 +0100 Message-ID: To: Amir Taaki Content-Type: multipart/alternative; boundary=0015174481ecbbc7d804b0c7368e X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (decker.christian[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1RLiQa-0007Qn-8l Cc: "bitcoin-development@lists.sourceforge.net" Subject: Re: [Bitcoin-development] Lock protocol version numbers X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 21:32:57 -0000 --0015174481ecbbc7d804b0c7368e Content-Type: text/plain; charset=ISO-8859-1 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 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@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > --0015174481ecbbc7d804b0c7368e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I don't really get what you want to achieve with this. The protocol wil= l 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 coupl= ing makes no sense.

Regards,
Chris
On Wed, Nov 2, 2011 at = 10:23 PM, Amir Taaki <zgenjix@yahoo.com> wrote:
Hey,

=
Can we lock the version numbers to be the protocol version (which chan= ges rarely) and instead use the sub_version_num field + revision number for= individual builds?

Satoshi 0.4
BitcoinJava 120311
bitc= oin-js 6

Like so. Otherwise we will have version b= umping insanity :)

-----------------------------------= -------------------------------------------
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.s= f.net/sfu/rsa-sfdev2dev1
___________________________________________= ____
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment


--0015174481ecbbc7d804b0c7368e--