[bitcoin-dev] Bitcoin Core 0.12.0 release schedule

ACK

On Thu, Sep 24, 2015 at 7:25 AM, Wladimir J. van der Laan via bitcoin-dev <

Post by Wladimir J. van der Laan via bitcoin-dev
Hello all,
The next major release of Bitcoin Core, 0.12.0 is planned for the end of
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Luke Dashjr via bitcoin-dev

2015-09-30 17:57:42 UTC

On Thursday, September 24, 2015 11:25:56 AM Wladimir J. van der Laan via

Post by Wladimir J. van der Laan via bitcoin-dev
2015-12-01
-----------
- Feature freeze

Jorge Timón via bitcoin-dev

2015-09-30 18:10:30 UTC

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

Post by Luke Dashjr via bitcoin-dev
On Thursday, September 24, 2015 11:25:56 AM Wladimir J. van der Laan via

Post by Wladimir J. van der Laan via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Jeff Garzik via bitcoin-dev

2015-09-30 19:24:29 UTC

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 <

Post by Luke Dashjr via bitcoin-dev
On Thursday, September 24, 2015 11:25:56 AM Wladimir J. van der Laan via

Post by Wladimir J. van der Laan via bitcoin-dev
2015-12-01
-----------
- Feature freeze

Wladimir J. van der Laan via bitcoin-dev

2015-10-01 08:50:59 UTC

Post by Luke Dashjr via bitcoin-dev
On Thursday, September 24, 2015 11:25:56 AM Wladimir J. van der Laan via

Post by Wladimir J. van der Laan via bitcoin-dev
2015-12-01
-----------
- Feature freeze

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

Marcel Jamin via bitcoin-dev

2015-10-01 09:05:59 UTC

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 <

Post by Luke Dashjr via bitcoin-dev
On Thursday, September 24, 2015 11:25:56 AM Wladimir J. van der Laan via

Post by Wladimir J. van der Laan via bitcoin-dev
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

Post by Luke Dashjr via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Btc Drak via bitcoin-dev

2015-10-01 09:17:52 UTC

On Thu, Oct 1, 2015 at 10:05 AM, Marcel Jamin via bitcoin-dev <

Post by Marcel Jamin via bitcoin-dev
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.

Marcel Jamin via bitcoin-dev

2015-10-01 09:41:25 UTC

---------- Forwarded message ----------
From: Marcel Jamin <***@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 <***@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.

Post by Btc Drak via bitcoin-dev
On Thu, Oct 1, 2015 at 10:05 AM, Marcel Jamin via bitcoin-dev <

Post by Marcel Jamin via bitcoin-dev
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.

Wladimir J. van der Laan via bitcoin-dev

2015-10-01 09:56:55 UTC

Post by Marcel Jamin via bitcoin-dev
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

Marcel Jamin via bitcoin-dev

2015-10-01 10:10:45 UTC

Post by Wladimir J. van der Laan via bitcoin-dev
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).

Post by Wladimir J. van der Laan via bitcoin-dev
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.

Post by Wladimir J. van der Laan via bitcoin-dev
We're horribly stressed-out as is.

Yeah, probably not a very important topic right now.

Post by Marcel Jamin via bitcoin-dev
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

Wladimir J. van der Laan via bitcoin-dev

2015-10-01 10:15:45 UTC

Post by Marcel Jamin via bitcoin-dev
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)

Post by Marcel Jamin via bitcoin-dev
Then you could start using the version as a signaling mechanism.

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

Post by Marcel Jamin via bitcoin-dev
Yeah, probably not a very important topic right now.

Exactly.

Wladimir

Post by Marcel Jamin via bitcoin-dev
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

Marcel Jamin via bitcoin-dev

2015-10-01 10:34:38 UTC

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.

Post by Marcel Jamin via bitcoin-dev
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?

Post by Marcel Jamin via bitcoin-dev
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

Post by Wladimir J. van der Laan via bitcoin-dev
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

Post by Wladimir J. van der Laan via bitcoin-dev
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

Post by Wladimir J. van der Laan via bitcoin-dev
number. We're horribly stressed-out as is.
Wladimir

Jeff Garzik via bitcoin-dev

2015-10-01 10:50:35 UTC

On Thu, Oct 1, 2015 at 5:41 AM, Marcel Jamin via bitcoin-dev <

Post by Marcel Jamin via bitcoin-dev
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.

Luke Dashjr via bitcoin-dev

2015-10-01 20:20:22 UTC