Bitcoin Core 0.10 release schedule

> Let me know if there is anything else you think is ready (and not too
> risky) to be in 0.10.

> Now that headers-first is merged it would be good to do a 0.10
> release soon. Not *too* soon as a major code change like that takes
> some time to pan out, but I'd like to propose the following:
>
> - November 18: split off 0.10 branch, translation message and
> feature freeze - December 1: release 10.0rc1, start Release
> Candidate cycle
>
> That leaves three weeks until the freeze. After the release and
> branch split-off, the RC cycle will run until no critical problems
> are found. For major releases this is usually more painful than for
> stable releases, but if we can keep to these dates I'd expect the
> final release no later than January 2015.
>
> Let's aim to have any pending development for 0.10 merged before
> November 18. Major work that I'm aware of is:
>
> - BIP62 (#5134, #5065) - Verification library (#5086, #5118,
> #5119) - Gitian descriptors overhaul, so that Gitian depends =
> Travis depends (#4727) - Autoprune (#4701) - Add "warmup mode" for
> RPC server (#5007) - Add unauthenticated HTTP REST interface
> (#2844)
>
> Let me know if there is anything else you think is ready (and not
> too risky) to be in 0.10. You can help along the development
> process by participating in testing and reviewing of the mentioned
> pull requests, or just by testing master and reporting bugs and
> regressions.
>
> Note: I intended the 0.10 release to be much sooner. The reason
> that this didn't pan out is that I insisted on including
> headers-first, and this took longer than expected. There seems to
> be a preference to switch to a fixed (instead of feature-based)
> 6-month major release schedule, ie
>
> - July 2015: 0.11.0 (or whatever N+1 release is called) - January
> 2016: 0.12.0 (or whatever N+2 release is called) - July 2016:
> 0.13.0 (or whatever N+3 release is called)
>
> Wladimir
>
> ------------------------------------------------------------------------------
>
>

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Q., re. transaction fee changes / txconfirmtarget described at
> https://github.com/bitcoin/bitcoin/blob/c8a25189bcb1381eddf46b9a9743ba48e929439e/doc/release-notes.md
>
> (for Core 0.10)
>
> ~ does this include the floating fees for 0.10 as described at
> https://bitcoinfoundation.org/2014/07/floating-fees-for-0-10/ ?
>
> thanks in advance for clarifications

> Now that headers-first is merged it would be good to do a 0.10 release
> soon. Not *too* soon as a major code change like that takes some time
> to pan out, but I'd like to propose the following:
>
> - November 18: split off 0.10 branch, translation message and feature
> freeze
> - December 1: release 10.0rc1, start Release Candidate cycle
>
> That leaves three weeks until the freeze. After the release and branch
> split-off, the RC cycle will run until no critical problems are found.
> For major releases this is usually more painful than for stable
> releases, but if we can keep to these dates I'd expect the final
> release no later than January 2015.
>
> Let's aim to have any pending development for 0.10 merged before
> November 18. Major work that I'm aware of is:
>
> - BIP62 (#5134, #5065)
> - Verification library (#5086, #5118, #5119)
> - Gitian descriptors overhaul, so that Gitian depends = Travis depends
> (#4727)
> - Autoprune (#4701)
> - Add "warmup mode" for RPC server (#5007)
> - Add unauthenticated HTTP REST interface (#2844)
>

>
> Let me know if there is anything else you think is ready (and not too
> risky) to be in 0.10. You can help along the development process by
> participating in testing and reviewing of the mentioned pull requests,
> or just by testing master and reporting bugs and regressions.
>
> Note: I intended the 0.10 release to be much sooner. The reason that
> this didn't pan out is that I insisted on including headers-first, and
> this took longer than expected. There seems to be a preference to
> switch to a fixed (instead of feature-based) 6-month major release
> schedule, ie
>
> - July 2015: 0.11.0 (or whatever N+1 release is called)
> - January 2016: 0.12.0 (or whatever N+2 release is called)
> - July 2016: 0.13.0 (or whatever N+3 release is called)
>
> Wladimir
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

> On Sun, Oct 26, 2014 at 9:55 AM, odinn
> <odinn.cyberguerrilla@riseup•net> wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
>>
>> Q., re. transaction fee changes / txconfirmtarget described at
>> https://github.com/bitcoin/bitcoin/blob/c8a25189bcb1381eddf46b9a9743ba48e929439e/doc/release-notes.md
>>
>>
>>

>>
>> ~ does this include the floating fees for 0.10 as described at
>> https://bitcoinfoundation.org/2014/07/floating-fees-for-0-10/ ?
>>
>> thanks in advance for clarifications
>
> Yes, floating/smart fees has been merged a while ago
>
> - https://github.com/bitcoin/bitcoin/pull/3959 -
> https://github.com/bitcoin/bitcoin/pull/4250
>
> Wladimir
>

> On Sunday, October 26, 2014 7:57:12 AM Wladimir wrote:
>> Let me know if there is anything else you think is ready (and not too
>> risky) to be in 0.10.
>
> At the very least, we need:
>   #5106 Bugfix: submitblock: Use a temporary CValidationState to determine ...
>   #5103 CreateNewBlock and miner_tests: Also check generated template is ...
>   #5078 Bugfix: CreateNewBlock: Check that active chain has a valid tip ...
>         (or at least some conclusion for the problem discussed therein)

> Harmless/No reason not to have:
>   #3727 RPC: submitblock: Support for returning specific rejection reasons
>   #1816 Support for BIP 23 block proposal
>   #5144 Qt: Elaborate on signverify message dialog warning
>   #5071 Introduce CNodePolicy for putting isolated node policy code and ...
>         (futher commits exist that should ideally get in after this is merged)

> Debatable (but harmless, and miners seem to want it):
>   #5077 Enable customising node policy for datacarrier data size with a ...

> Firstly, apologies in coming in late to the conversation.  As I am also
> working on a REST API for electronic coins.  Some questions:
>
> 1. Is there a BIP, or some other doc (e.g. gist), outlining the REST output
> e.g. the response format and MIME types.  Or just compile from source?

> 2. How set in stone is v1 of the the going forward?  PS I support @maaku's
> comments re: "/api/v1/" -- tho I guess it is too late for that now.
> 3. Would there be any support to develop this interface into something that
> would be W3C standards compliant, or reviewed by the REST community.  So for
> example a context can be provided to self document the terms (something I've
> almost completed) and would allow standardization of block explorer and
> bitcoind outputs.  Right now every explorer seems to have a different JSON
> output.

> On Sun, Oct 26, 2014 at 12:44 PM, Melvin Carvalho
> <melvincarvalho@gmail•com> wrote:
>
> > Firstly, apologies in coming in late to the conversation.  As I am also
> > working on a REST API for electronic coins.  Some questions:
> >
> > 1. Is there a BIP, or some other doc (e.g. gist), outlining the REST
> output
> > e.g. the response format and MIME types.  Or just compile from source?
>
> See the opening post from @jgarzik, it has some documentation on how
> to use the API.
>
> It would be nice to have some write-up about the current functionality
> in the release notes, but there currently is none.
>
> It's a RPC-side change, not a P2P-side change so it doesn't require a BIP.
>

>
> > 2. How set in stone is v1 of the the going forward?  PS I support
> @maaku's
> > comments re: "/api/v1/" -- tho I guess it is too late for that now.
> > 3. Would there be any support to develop this interface into something
> that
> > would be W3C standards compliant, or reviewed by the REST community.  So
> for
> > example a context can be provided to self document the terms (something
> I've
> > almost completed) and would allow standardization of block explorer and
> > bitcoind outputs.  Right now every explorer seems to have a different
> JSON
> > output.
>
> It's not too late, it's not been merged yet.
>
> Though a W3C standard takes a long time to pan out, and it may be more
> useful to have this available rather than wait for the API to be
> standardized (which means this will need to be postponed at least one
> version). As you say, a new interface be added later under another
> URI.
>

>
> Note that we're only interested in exposing read-only, public data
> which is already available in Bitcoin Core's internals.
> We're not aiming to add a fully-fledged block explorer with (say)
> address indexes. Although that could be part of the standard if it
> allows implementations to support just a subset.
>

>
> Anyhow - please coordinate this with Jeff Garzik, it's better to work
> together here.
>

>
> Wladimir
>

> Do you think it would a reasonable idea to put down some thoughts and
> proposals in a BIP?