Bitcoin Core 0.12.0 release schedule
15 messages, 24 Sep to 1 Oct 2015. Started by Wladimir J. van der Laan.
Wladimir J. van der Laan (4), Marcel Jamin (4), Jeff Garzik (3), Luke Dashjr (2), Jorge Timón, Btc Drak
Hello all,
The next major release of Bitcoin Core, 0.12.0 is planned for the end of the year. Let's propose a more detailed schedule:
2015-11-01 ----------- - Open Transifex translations for 0.12 - Soft translation string freeze (no large or unnecessary changes) - Finalize and close translation for 0.10
2015-12-01 ----------- - Feature freeze - Translation string freeze
In December at least I will probably not get much done code-wise (Scaling Bitcoin Hongkong, 32C3, end of year festivities, etc), and I'm sure I'm not the only one, so let's leave that for last pre-RC bugfixes and polishing.
2016-01-06 ----------- - Split off `0.12` branch from `master` - Start RC cycle, tag and release `0.12.0rc1` - Start merging for 0.13 on master branch
2016-02-01 ----------- - Release 0.12.0 final (aim)
Wladimir
ACK
On Thu, Sep 24, 2015 at 7:25 AM, Wladimir J. van der Laan via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (38 lines)
> Hello all, > > The next major release of Bitcoin Core, 0.12.0 is planned for the end of > the year. Let's propose a more detailed schedule: > > 2015-11-01 > ----------- > - Open Transifex translations for 0.12 > - Soft translation string freeze (no large or unnecessary changes) > - Finalize and close translation for 0.10 > > 2015-12-01 > ----------- > - Feature freeze > - Translation string freeze > > In December at least I will probably not get much done code-wise (Scaling > Bitcoin Hongkong, 32C3, end of year festivities, etc), and I'm sure I'm not > the only one, so let's leave that for last pre-RC bugfixes and polishing. > > 2016-01-06 > ----------- > - Split off `0.12` branch from `master` > - Start RC cycle, tag and release `0.12.0rc1` > - Start merging for 0.13 on master branch > > 2016-02-01 > ----------- > - Release 0.12.0 final (aim) > > Wladimir > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >
On Thursday, September 24, 2015 11:25:56 AM Wladimir J. van der Laan via bitcoin-dev wrote:
Quoted text (3 lines)
> 2015-12-01 > ----------- > - Feature freeze
Where is "Consensus freeze"? Shouldn't this be put off until after the HK workshop in case a hardfork is decided on? Or have we de-coupled it from the release process entirely anyway (since old versions need an update for it too)?
Luke
Yes, I believe consensus rule changes don't need to be couple with major releases, there's no problem that I can see in them being minor releases if they're not ready on time for a major release.
On Wed, Sep 30, 2015 at 7:57 PM, Luke Dashjr via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (16 lines)
> On Thursday, September 24, 2015 11:25:56 AM Wladimir J. van der Laan via > bitcoin-dev wrote: >> 2015-12-01 >> ----------- >> - Feature freeze > > Where is "Consensus freeze"? Shouldn't this be put off until after the HK > workshop in case a hardfork is decided on? Or have we de-coupled it from the > release process entirely anyway (since old versions need an update for it > too)? > > Luke > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Right; In general, the consensus is to decouple from Bitcoin Core releases.
On Wed, Sep 30, 2015 at 1:57 PM, Luke Dashjr via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (18 lines)
> On Thursday, September 24, 2015 11:25:56 AM Wladimir J. van der Laan via > bitcoin-dev wrote: > > 2015-12-01 > > ----------- > > - Feature freeze > > Where is "Consensus freeze"? Shouldn't this be put off until after the HK > workshop in case a hardfork is decided on? Or have we de-coupled it from > the > release process entirely anyway (since old versions need an update for it > too)? > > Luke > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >
On Wed, Sep 30, 2015 at 05:57:42PM +0000, Luke Dashjr wrote:
Quoted text (10 lines)
> On Thursday, September 24, 2015 11:25:56 AM Wladimir J. van der Laan via > bitcoin-dev wrote: > > 2015-12-01 > > ----------- > > - Feature freeze > > Where is "Consensus freeze"? Shouldn't this be put off until after the HK > workshop in case a hardfork is decided on? Or have we de-coupled it from the > release process entirely anyway (since old versions need an update for it > too)?
In principle, "feature freeze" means that any large code changes will no longer go into 0.12, unless fixing critical bugs.
I'm not keen on postponing 0.12 for such reasons - after the HK workshop I'm sure that it will take some development/testing/review before code makes it into anything. Apart from that there's a good point to decouple consensus changes from Bitcoin Core major releases.
We've seen lot of release date drift due to "this and this change needs to make it in" in the past, that was a major reason to switch to a time-based instead of feature-based release schedule.
We can always do a 0.12.1.
Wladimir
Any particular reason bitcoin versioning doesn't follow the SemVer spec?
2015-10-01 10:50 GMT+02:00 Wladimir J. van der Laan via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org>:
Quoted text (33 lines)
> On Wed, Sep 30, 2015 at 05:57:42PM +0000, Luke Dashjr wrote: > > On Thursday, September 24, 2015 11:25:56 AM Wladimir J. van der Laan via > > bitcoin-dev wrote: > > > 2015-12-01 > > > ----------- > > > - Feature freeze > > > > Where is "Consensus freeze"? Shouldn't this be put off until after the HK > > workshop in case a hardfork is decided on? Or have we de-coupled it from > the > > release process entirely anyway (since old versions need an update for it > > too)? > > In principle, "feature freeze" means that any large code changes will no > longer go into 0.12, unless fixing critical bugs. > > I'm not keen on postponing 0.12 for such reasons - after the HK workshop > I'm sure that it will take some development/testing/review before code > makes it into anything. Apart from that there's a good point to decouple > consensus changes from Bitcoin Core major releases. > > We've seen lot of release date drift due to "this and this change needs to > make it in" in the past, that was a major reason to switch to a time-based > instead of feature-based release schedule. > > We can always do a 0.12.1. > > Wladimir > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >
On Thu, Oct 1, 2015 at 10:05 AM, Marcel Jamin via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (2 lines)
> Any particular reason bitcoin versioning doesn't follow the SemVer spec? >
We do: a.b.c, the next major version is, 0.12.0, and maintenance releases are 0.12.1 etc. Release candidates are 0.12.0-rc1 for example.
---------- Forwarded message ---------- From: Marcel Jamin <marcel@jamin•net> Date: 2015-10-01 11:39 GMT+02:00 Subject: Re: [bitcoin-dev] Bitcoin Core 0.12.0 release schedule To: Btc Drak <btcdrak@gmail•com>
I guess the question then becomes why bitcoin still is <1.0.0
I'd say it's safe to say that it's used in production.
2015-10-01 11:17 GMT+02:00 Btc Drak <btcdrak@gmail•com>:
Quoted text (9 lines)
> On Thu, Oct 1, 2015 at 10:05 AM, Marcel Jamin via bitcoin-dev < > bitcoin-dev@lists•linuxfoundation•org> wrote: > >> Any particular reason bitcoin versioning doesn't follow the SemVer spec? >> > > We do: a.b.c, the next major version is, 0.12.0, and maintenance releases > are 0.12.1 etc. Release candidates are 0.12.0-rc1 for example. >
On Thu, Oct 01, 2015 at 11:41:25AM +0200, Marcel Jamin wrote:
Quoted text (1 line)
> I guess the question then becomes why bitcoin still is <1.0.0
I'll interpret the question as "why is the Bitcoin Core software still <1.0.0". Bitcoin the currency doesn't have a version, the block/transaction versions are at v3/v1 respectively, and the highest network protocol version is 70011.
Mostly because we don't use the numbers as a signaling mechanism. They just count up, every half year.
Otherwise, one'd have to ask hard questions like 'is the software mature enough to be called 1.0.0', which would lead to long arguments, all of which would eventually lead to nothing more than potentially increasing a number. We're horribly stressed-out as is.
Wladimir
Quoted text (1 line)
> Mostly because we don't use the numbers as a signaling mechanism. They
just count up, every half year.
OK, but then it's not semantic versioning (as btcdrak claims).
Quoted text (1 line)
> Otherwise, one'd have to ask hard questions like 'is the software mature
enough to be called 1.0.0'
I think the question has already been answered for you by the companies that build on top of it, the investments being made and the $3.5 billion market cap. The 1.0.0 tag is probably long overdue.
Then you could start using the version as a signaling mechanism.
Quoted text (1 line)
> We're horribly stressed-out as is.
Yeah, probably not a very important topic right now.
2015-10-01 11:56 GMT+02:00 Wladimir J. van der Laan <laanwj@gmail•com>:
Quoted text (18 lines)
> On Thu, Oct 01, 2015 at 11:41:25AM +0200, Marcel Jamin wrote: > > I guess the question then becomes why bitcoin still is <1.0.0 > > I'll interpret the question as "why is the Bitcoin Core software still > <1.0.0". Bitcoin the currency doesn't have a version, the block/transaction > versions are at v3/v1 respectively, and the highest network protocol > version is 70011. > > Mostly because we don't use the numbers as a signaling mechanism. They > just count up, every half year. > > Otherwise, one'd have to ask hard questions like 'is the software mature > enough to be called 1.0.0', which would lead to long arguments, all of > which would eventually lead to nothing more than potentially increasing a > number. We're horribly stressed-out as is. > > Wladimir >
On Thu, Oct 01, 2015 at 12:10:45PM +0200, Marcel Jamin wrote:
Quoted text (3 lines)
> I think the question has already been answered for you by the companies > that build on top of it, the investments being made and the $3.5 billion > market cap. The 1.0.0 tag is probably long overdue.
May I remind you that by far, most of that investment is not in the Bitcoin Core software.
It is made to things building on top of the network/protocol, under the assumption that nothing really stupid will happen and the network will not go down etc.
This implies a level of trust in the node software to maintain consensus, but doesn't necessarily mean that all rough corners have been dealt with regarding implementation.
(but this is exactly the kind of argument I'm trying to avoid getting pulled into)
Quoted text (1 line)
> Then you could start using the version as a signaling mechanism.
We certainly could, it is a decision to not to.
Quoted text (1 line)
> Yeah, probably not a very important topic right now.
Exactly.
Wladimir
Quoted text (23 lines)
> > > > 2015-10-01 11:56 GMT+02:00 Wladimir J. van der Laan <laanwj@gmail•com>: > > > On Thu, Oct 01, 2015 at 11:41:25AM +0200, Marcel Jamin wrote: > > > I guess the question then becomes why bitcoin still is <1.0.0 > > > > I'll interpret the question as "why is the Bitcoin Core software still > > <1.0.0". Bitcoin the currency doesn't have a version, the block/transaction > > versions are at v3/v1 respectively, and the highest network protocol > > version is 70011. > > > > Mostly because we don't use the numbers as a signaling mechanism. They > > just count up, every half year. > > > > Otherwise, one'd have to ask hard questions like 'is the software mature > > enough to be called 1.0.0', which would lead to long arguments, all of > > which would eventually lead to nothing more than potentially increasing a > > number. We're horribly stressed-out as is. > > > > Wladimir > >
2015-10-01 12:15 GMT+02:00 Wladimir J. van der Laan <laanwj@gmail•com>:
Quoted text (8 lines)
> On Thu, Oct 01, 2015 at 12:10:45PM +0200, Marcel Jamin wrote: > > I think the question has already been answered for you by the companies > > that build on top of it, the investments being made and the $3.5 billion > > market cap. The 1.0.0 tag is probably long overdue. > > May I remind you that by far, most of that investment is not in the > Bitcoin Core software. >
As I understand it, right now the bitcoin protocol is defined by the bitcoin core implementation. Or is there anything else to point to? So I'd say my point still stands.
Other implementations copy what bitcoin core does.
Quoted text (4 lines)
> > Then you could start using the version as a signaling mechanism. > > We certainly could, it is a decision to not to. >
Simply because of the "1.0.0" issue or for other reasons as well?
Quoted text (24 lines)
> 2015-10-01 11:56 GMT+02:00 Wladimir J. van der Laan <laanwj@gmail•com>: > > > > > On Thu, Oct 01, 2015 at 11:41:25AM +0200, Marcel Jamin wrote: > > > > I guess the question then becomes why bitcoin still is <1.0.0 > > > > > > I'll interpret the question as "why is the Bitcoin Core software still > > > <1.0.0". Bitcoin the currency doesn't have a version, the > block/transaction > > > versions are at v3/v1 respectively, and the highest network protocol > > > version is 70011. > > > > > > Mostly because we don't use the numbers as a signaling mechanism. They > > > just count up, every half year. > > > > > > Otherwise, one'd have to ask hard questions like 'is the software > mature > > > enough to be called 1.0.0', which would lead to long arguments, all of > > > which would eventually lead to nothing more than potentially > increasing a > > > number. We're horribly stressed-out as is. > > > > > > Wladimir > > > >
On Thu, Oct 1, 2015 at 5:41 AM, Marcel Jamin via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (2 lines)
> I guess the question then becomes why bitcoin still is <1.0.0 >
I've said the same thing years ago. Originally the "1.0" was a target for whenever "client mode" as planned by Satoshi was implemented, making the Bitcoin Core implementation feature-complete for as a minimum working/viable project.
Ultimately it is not so important and tends to generate a lot of discussion - so maybe we should just do the emacs thing and go from 0.12 to 12.0 for next version.
On Thursday, October 01, 2015 9:41:25 AM Marcel Jamin via bitcoin-dev wrote:
Quoted text (3 lines)
> I guess the question then becomes why bitcoin still is <1.0.0 > > I'd say it's safe to say that it's used in production.
But it's not *ready* to be used in production. :(
For 1.0, I would expect:
libbitcoinconsensus: an API that makes implementing a full node practical.
Bitcoin Core GUI: reasonably usable safely by non-technical people.
Bitcoin Core Daemon: a reasonably safe wallet (currently blocked by backup- resistant accounting system)
Luke