[bitcoin-dev] Bitcoin Core 0.12.0 release schedule

[bitcoin-dev] Bitcoin Core 0.12.0 release schedule

[Wladimir J. van der Laan]

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

Re: [bitcoin-dev] Bitcoin Core 0.12.0 release schedule

[Jeff Garzik]

[-- Attachment #1: Type: text/plain, Size: 1188 bytes --]

ACK


On Thu, Sep 24, 2015 at 7:25 AM, Wladimir J. van der Laan via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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
>

[-- Attachment #2: Type: text/html, Size: 1801 bytes --]

Re: [bitcoin-dev] Bitcoin Core 0.12.0 release schedule

[Luke Dashjr]

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

Re: [bitcoin-dev] Bitcoin Core 0.12.0 release schedule

[Jorge Timón]

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:
> 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

Re: [bitcoin-dev] Bitcoin Core 0.12.0 release schedule

[Jeff Garzik]

[-- Attachment #1: Type: text/plain, Size: 772 bytes --]

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:

> 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
>

[-- Attachment #2: Type: text/html, Size: 1405 bytes --]

Re: [bitcoin-dev] Bitcoin Core 0.12.0 release schedule

[Wladimir J. van der Laan]

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

Re: [bitcoin-dev] Bitcoin Core 0.12.0 release schedule

[Marcel Jamin]

[-- Attachment #1: Type: text/plain, Size: 1496 bytes --]

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>:

> 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
>

[-- Attachment #2: Type: text/html, Size: 2137 bytes --]

Re: [bitcoin-dev] Bitcoin Core 0.12.0 release schedule

[Btc Drak]

[-- Attachment #1: Type: text/plain, Size: 326 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 675 bytes --]

[bitcoin-dev] Fwd: Bitcoin Core 0.12.0 release schedule

[Marcel Jamin]

[-- Attachment #1: Type: text/plain, Size: 727 bytes --]

---------- 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>:

> 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.
>

[-- Attachment #2: Type: text/html, Size: 1620 bytes --]

Re: [bitcoin-dev] Fwd: Bitcoin Core 0.12.0 release schedule

[Wladimir J. van der Laan]

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

Re: [bitcoin-dev] Fwd: Bitcoin Core 0.12.0 release schedule

[Marcel Jamin]

[-- Attachment #1: Type: text/plain, Size: 1473 bytes --]

> 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).

> 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.

> 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>:

> 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
>

[-- Attachment #2: Type: text/html, Size: 2759 bytes --]

Re: [bitcoin-dev] Fwd: Bitcoin Core 0.12.0 release schedule

[Wladimir J. van der Laan]

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.

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)

> Then you could start using the version as a signaling mechanism.

We certainly could, it is a decision to not to.

> Yeah, probably not a very important topic right now.

Exactly.

Wladimir
> 
> 
> 
> 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
> >

Re: [bitcoin-dev] Fwd: Bitcoin Core 0.12.0 release schedule

[Marcel Jamin]

[-- Attachment #1: Type: text/plain, Size: 1791 bytes --]

2015-10-01 12:15 GMT+02:00 Wladimir J. van der Laan <laanwj@gmail.com>:

> 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.


> > 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?



> 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
> > >
>

[-- Attachment #2: Type: text/html, Size: 2974 bytes --]

Re: [bitcoin-dev] Fwd: Bitcoin Core 0.12.0 release schedule

[Jeff Garzik]

[-- Attachment #1: Type: text/plain, Size: 577 bytes --]

On Thu, Oct 1, 2015 at 5:41 AM, Marcel Jamin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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.

[-- Attachment #2: Type: text/html, Size: 1003 bytes --]

Re: [bitcoin-dev] Fwd: Bitcoin Core 0.12.0 release schedule

[Luke Dashjr]

On Thursday, October 01, 2015 9:41:25 AM Marcel Jamin via bitcoin-dev wrote:
> 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