From: Marcel Jamin <marcel@jamin.net>
To: "Wladimir J. van der Laan" <laanwj@gmail.com>
Cc: Bitcoin development mailing list <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Bitcoin Core 0.12.0 release schedule
Date: Thu, 1 Oct 2015 11:05:59 +0200 [thread overview]
Message-ID: <CAAUq486=TisNp0MbFjWYdCsyVX-qx5dV_KKZuNR7Jp63KNWeiQ@mail.gmail.com> (raw)
In-Reply-To: <20151001085058.GA10010@amethyst.visucore.com>
[-- 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 --]
next prev parent reply other threads:[~2015-10-01 9:06 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-24 11:25 [bitcoin-dev] Bitcoin Core 0.12.0 release schedule Wladimir J. van der Laan
2015-09-29 21:22 ` Jeff Garzik
2015-09-30 17:57 ` Luke Dashjr
2015-09-30 18:10 ` Jorge Timón
2015-09-30 19:24 ` Jeff Garzik
2015-10-01 8:50 ` Wladimir J. van der Laan
2015-10-01 9:05 ` Marcel Jamin [this message]
2015-10-01 9:17 ` Btc Drak
[not found] ` <CAAUq484+g89yD+s7iR_mGWPM3TTN7V6-EPb1ig=P1BKfcbztPg@mail.gmail.com>
2015-10-01 9:41 ` [bitcoin-dev] Fwd: " Marcel Jamin
2015-10-01 9:56 ` Wladimir J. van der Laan
2015-10-01 10:10 ` Marcel Jamin
2015-10-01 10:15 ` Wladimir J. van der Laan
2015-10-01 10:34 ` Marcel Jamin
2015-10-01 10:50 ` Jeff Garzik
2015-10-01 20:20 ` Luke Dashjr
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAAUq486=TisNp0MbFjWYdCsyVX-qx5dV_KKZuNR7Jp63KNWeiQ@mail.gmail.com' \
--to=marcel@jamin.net \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=laanwj@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox