On Wed, Nov 2, 2011 at 7:22 PM, Christian Decker
wrote:
> The mainline client (independently from the GUI) has been referenced to as
> "Satoshi" client. I personally like the name as a homage, but I guess it all
> comes down to the decision of the maintainers.
That's how I take it to mean: "sato
The mainline client (independently from the GUI) has been referenced to as
"Satoshi" client. I personally like the name as a homage, but I guess it
all comes down to the decision of the maintainers.
Regards,
Chris
On Thu, Nov 3, 2011 at 12:07 AM, Luke-Jr wrote:
> On Wednesday, November 02, 2011
On Wednesday, November 02, 2011 6:55:27 PM Amir Taaki wrote:
> I think calling it Satoshi is apt homage to the person who made the
> original client reference protocol.
My point is that the "Satoshi client" was the wxWidgets client, which was
retired by 0.5.
-
Cool thread. I enjoyed reading that :) Thanks for sharing.
From: Christian Decker
To: Amir Taaki
Cc: "bitcoin-development@lists.sourceforge.net"
Sent: Wednesday, November 2, 2011 10:42 PM
Subject: Re: [Bitcoin-development] Lock protocol version numbers
Just
Bitcoin is the protocol. The client protocol identifier needs a unique name. It
is not a public name that anybody ever sees except protocol developers.
For instance with libbitcoin, there might be several clients using it, but
they'd all have the same protocol identifier.
I think calling it Sat
On Wednesday, November 02, 2011 6:33:12 PM Amir Taaki wrote:
> "Satoshi 0.5"
What is "Satoshi 0.5" anyway? 0.5's server is bitcoind and GUI is Bitcoin-Qt;
the wx GUI client is gone, which is more or less what "Satoshi" referred to in
the past...
-
Just for reference: https://github.com/bitcoin/bitcoin/pull/63
The issue resulted in my most useless pull request fixing two variables :-)
I second the use of sub_version_num as a Client and Version identifier.
Regards,
Chris
On Wed, Nov 2, 2011 at 11:33 PM, Amir Taaki wrote:
> Point taken.
>
Point taken.
About the sub_version_num though. I prefer to let the field by defined clients
however they wish, with just a guideline suggestion that IDENTIFIER VERSION is
a format they should follow.
The idea being that different projects would have different release scheduling
schemes and it'
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
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 :)
10 matches
Mail list logo
