Version 0.7 release planning

There seems to be consensus that we should go ahead and do a release, before leveldb or ultraprune or anything major lands. There is no major landmark feature, but just a useful collection of small changes. It seems like a good time to Release Early, Release Often and make a checkpoint release.

Some rough draft release notes were dumped in https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes.txt

Opening the floor... What do we collectively want to happen, before 0.7 release? What is the todo list for 0.7?

After cleaning out some pull requests yesterday, and looking at the list today, I see

1) CreateNewBlock: Child-pays-for-parent / Add transaction fee later luke-jr https://github.com/bitcoin/bitcoin/pull/1647

2) Translations update 2012-08-01 (fetched from Transifex) Diapolo https://github.com/bitcoin/bitcoin/pull/1644

3) Add address groupings RPC from coderrr's coincontrol patches. gmaxwell https://github.com/bitcoin/bitcoin/pull/1642

4) Add 'mempool' P2P command, and extend 'getdata' behavior jgarzik https://github.com/bitcoin/bitcoin/pull/1641

5) PROBABLY NOT, BUT MAYBE: Relay blocks as a "preview" before checking the transactions in them luke-jr https://github.com/bitcoin/bitcoin/pull/1586

6) JSON-RPC method: prioritisetransaction <txid> <priority delta> luke-jr https://github.com/bitcoin/bitcoin/pull/1583

7) HOPEFULLY: Addnode optimization and addnode access via RPC BlueMatt https://github.com/bitcoin/bitcoin/pull/1549

8) MAYBE: Transition to requiring block height in block coinbases gavinandresen https://github.com/bitcoin/bitcoin/pull/1526

9) WE MUST PICK ONE: RPC: lock push-down, preparing for
parallelization opportunities
jgarzik https://github.com/bitcoin/bitcoin/pull/1494
    or
RPC: add facility to enable RPCs to run outside cs_main, wallet locks
jgarzik https://github.com/bitcoin/bitcoin/pull/1493

10) I THINK WE WANT THIS? Make IPv6 support optional again (defaults to enabled) luke-jr https://github.com/bitcoin/bitcoin/pull/1431

11) MAYBE: getblocktemplate ('getmemorypool', post IRC debate) luke-jr https://github.com/bitcoin/bitcoin/pull/936

Devs -- feel free to commit directly to doc/release-notes.txt if there is a missing commit, or something that may be better described.

On Thu, Aug 2, 2012 at 12:43 PM, Jeff Garzik <jgarzik@exmulti•com> wrote:

> There seems to be consensus that we should go ahead and do a release,
> before leveldb or ultraprune or anything major lands.  There is no
> major landmark feature, but just a useful collection of small changes.
>  It seems like a good time to Release Early, Release Often and make a
> checkpoint release.

Procedural note: since Gavin is on vacation, this release obviously won't occur for at least a couple weeks.

If Gavin appears on email or IRC, though, I might try to pounce on him and convince him to let us go ahead with 0.7-rc1, if the other devs are happy.

On Thursday, August 02, 2012 4:43:25 PM Jeff Garzik wrote:

> Opening the floor...  What do we collectively want to happen, before
> 0.7 release?  What is the todo list for 0.7?

Based on pull-capable dev comments, I've personally noted these branches as accepted for 0.7:

> 7) HOPEFULLY: Addnode optimization and addnode access via RPC
> BlueMatt https://github.com/bitcoin/bitcoin/pull/1549
>
> 8) MAYBE: Transition to requiring block height in block coinbases
> gavinandresen https://github.com/bitcoin/bitcoin/pull/1526
>
> 10) I THINK WE WANT THIS?  Make IPv6 support optional again (defaults
> to enabled)
> luke-jr https://github.com/bitcoin/bitcoin/pull/1431
>
> 11) MAYBE: getblocktemplate ('getmemorypool', post IRC debate)
> luke-jr https://github.com/bitcoin/bitcoin/pull/936

+ + m) getmemorypool: longpolling support + luke-jr https://github.com/bitcoin/bitcoin/pull/1355 + + m) Refactor transaction/accounting time + luke-jr https://github.com/bitcoin/bitcoin/pull/1393

I also personally feel these are appropriate and ready for 0.7:

> 4) Add 'mempool' P2P command, and extend 'getdata' behavior
> jgarzik https://github.com/bitcoin/bitcoin/pull/1641
>
> 6) JSON-RPC method: prioritisetransaction <txid> <priority delta>
> luke-jr https://github.com/bitcoin/bitcoin/pull/1583
>
> 9) RPC: add facility to enable RPCs to run outside cs_main, wallet locks
> jgarzik https://github.com/bitcoin/bitcoin/pull/1493

+ + m) Treat generation (mined) transactions less different from receive + transactions + luke-jr https://github.com/bitcoin/bitcoin/pull/1409

Also these, but they need testing:

> 1) CreateNewBlock: Child-pays-for-parent / Add transaction fee later
> luke-jr https://github.com/bitcoin/bitcoin/pull/1647
>
> 5) PROBABLY NOT, BUT MAYBE: Relay blocks as a "preview" before
> checking the transactions in them
> luke-jr https://github.com/bitcoin/bitcoin/pull/1586

+ + m) Bitcoin-Qt (Windows only): enable DEP for bitcoin-qt.exe + diapolo https://github.com/bitcoin/bitcoin/pull/1614

I also feel it is very important that Wumpus/laanwj decide on a name for his client (formerly known as Bitcoin-Qt) and add it to the software instead of simply claiming it is "Bitcoin" as it has for a week or so now - that change is anticompetitive and will confuse new users into thinking Bitcoin is the software too easily.

Luke

I have no objections to a rc1 happening before I'm back.

On 02.08.2012 18:43, Jeff Garzik wrote:

> There seems to be consensus that we should go ahead and do a release,
> before leveldb or ultraprune or anything major lands.  There is no
> major landmark feature, but just a useful collection of small changes.
>  It seems like a good time to Release Early, Release Often and make a
> checkpoint release.

Looks like much goodness in this version. Thanks for all this work.

Any chance that options to limit the size of blocks and prioritize paid vs free txes could make it in?

By the way, by far the most common support request I have at my pool is users withdrawing coins and not seeing it in their wallet because it's not up-to-date with the block chain. Might be worth adding something in the bitcoin-qt GUI to make it more obvious that users can't see new transactions and why.

> 2) Translations update 2012-08-01 (fetched from Transifex)

I just now updated the Norwegian translation on Transifex, if you'd like to do another pull before the release. For some reason there were many strings I had already translated that now had no translation and had to be done again (even ones that had the same English text). Many languages are now only about 50% translated.

Also there were new duplicated strings:

"Verify a message to ensure it was signed with a specified Bitcoin address" "Sign a message to prove you own a Bitcoin address" "Clear &All"

These two seem odd: Use UPnP to map the listening port (default: 0) Use UPnP to map the listening port (default: 1 when listening)

Regards, Geir H. Hansen, bitminter.com

On Saturday, August 11, 2012 4:43:28 PM Geir Harald Hansen wrote:

> By the way, by far the most common support request I have at my pool is
> users withdrawing coins and not seeing it in their wallet because it's
> not up-to-date with the block chain. Might be worth adding something in
> the bitcoin-qt GUI to make it more obvious that users can't see new
> transactions and why.

Bitcoin-Qt even delays showing generation until 2 confirms.

> These two seem odd:
> Use UPnP to map the listening port (default: 0)
> Use UPnP to map the listening port (default: 1 when listening)

The default depends on build options, so that should be correct.

By the way, by far the most common support request I have at my pool is

> users withdrawing coins and not seeing it in their wallet because it's
> not up-to-date with the block chain. Might be worth adding something in
> the bitcoin-qt GUI to make it more obvious that users can't see new
> transactions and why.
>

For 0.7 we've added a red "(out of sync)" warning to the balances when the block chain is out of date.

However, due to the design of the protocol there is a large variance in block timings, and it is not possible to determine up-to-date status with certainty, so quite a large safety margin is used. To be precise the warning is shown when the last received block was generated more than 90 minutes ago.

Wladimir

Geir,

There were a lot of subtle changes to the English base messages such as capitalization or punctuation, I know this is pretty annoying for translators. It is a pity that there is no way to update all translations when the English base message changes but not significantly enough to trigger re-translation. I've looked but Transifex does not have that option.

Also there were new duplicated strings:

>
> "Verify a message to ensure it was signed with a specified Bitcoin address"
> "Sign a message to prove you own a Bitcoin address"
> "Clear &All"
>

Duplicate strings are not a problem. Some strings are used multiple times in the program, and thus appear multiple times in the translation. This is because there are cases in which a string that is the same in English is translated differently in another language based on the context.

At least Qt translator fills duplicates in automatically, with the option to change them if desired. I'm not sure about Transifex but I've heard it's the same there.

>
> These two seem odd:
> Use UPnP to map the listening port (default: 0)
> Use UPnP to map the listening port (default: 1 when listening)
>

The default depends on compiler flags, hence the two messages. I suppose the message could be split up, so that "Use UPnP to map the listening port" is factored out.

Let's do this after 0.7.0 release though, otherwise all the translations for those messages will be broken again. There should be no more message changes before the release unless there is a very good reason.

Wladimir

On 11.08.2012 20:56, Wladimir wrote:

> Duplicate strings are not a problem. Some strings are used multiple
> times in the program, and thus appear multiple times in the translation.
> This is because there are cases in which a string that is the same in
> English is translated differently in another language based on the context.

That makes sense. But it's hard to translate when you just see the same string twice and don't know the context where it will be used.

> At least Qt translator fills duplicates in automatically, with the
> option to change them if desired. I'm not sure about Transifex but I've
> heard it's the same there.

No, I just use copy and paste.

>     Use UPnP to map the listening port (default: 0)
>     Use UPnP to map the listening port (default: 1 when listening)
>
> The default depends on compiler flags, hence the two messages. I suppose
> the message could be split up, so that "Use UPnP to map the listening
> port" is factored out.

Sorry, forgot there was a compiler flag for this. No need to split this up. As long as there is no explanation or description for each string I think it's easier to translate whole sentences.

On 11.08.2012 20:32, Wladimir wrote:

> By the way, by far the most common support request I have at my pool is
>
>     users withdrawing coins and not seeing it in their wallet because it's
>     not up-to-date with the block chain. Might be worth adding

something in

>     the bitcoin-qt GUI to make it more obvious that users can't see new
>     transactions and why.
>
> For 0.7 we've added a red "(out of sync)" warning to the balances when
> the block chain is out of date.

Perfect. This will prevent a lot of confusion. Thanks!

Regards, Geir H. Hansen, bitminter.com