public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "Jorge Timón" <jtimon@jtimon•cc>
To: jg@112bit•com,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Planned Obsolescence
Date: Thu, 15 Dec 2016 19:48:47 +0100	[thread overview]
Message-ID: <CABm2gDo8DR9M9qKqhGfnRHNVrMVFGqsC-gJy4xtxT9=CQOBhgw@mail.gmail.com> (raw)
In-Reply-To: <615c88d2a1263810923705c170b25d33@112bit.com>

On Thu, Dec 15, 2016 at 4:38 AM, Juan Garavaglia via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> Older node versions may generate issues because some upgrades will make
> several of the nodes running older protocol versions obsolete and or
> incompatible. There may be other hard to predict behaviors on older versions
> of the client.

Hard to predict or not, you can't force people to run newer software.

> In order to avoid such wide fragmentation of "Bitcoin Core” node versions
> and to help there be a more predictable protocol improvement process, I
> consider it worth it to analyze introducing some planned obsolescence in
> each new version. In the last year we had 4 new versions so if each version
> is valid for about 1 year (52560 blocks) this may be a reasonable time frame
> for node operators to upgrade. If a node does not upgrade it will stop
> working instead of participating in the network with an outdated protocol
> version.

When you introduce anti-features like this in free software they can
be trivially removed and they likely will.

> These changes may also simplify the developer's jobs in some cases by
> avoiding them having to deal with ancient versions of the client.

There's a simpler solution for this which is what is being done now:
stop maintaining and giving support for older versions.
There's limited resources and developers are rarely interested in
fixing bugs for very old versions. Users shouldn't expect things to be
backported to old versions (if developers do it and there's enough
testing, there's no reason not to do more releases of old versions, it
is just rarely the case).


  parent reply	other threads:[~2016-12-15 18:48 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <f27bd300c20d1b48cddc7e1d1dc1a96c@112bit.com>
2016-12-15  3:38 ` jg
2016-12-15 18:12   ` Aymeric Vitte
2016-12-15 18:48   ` Jorge Timón [this message]
2016-12-15 22:25     ` Angel Leon
2016-12-15 22:44     ` Ethan Heilman
2016-12-18 10:34       ` Matt Corallo
2016-12-18 20:50         ` Chris Riley
2016-12-18 20:07   ` Alice Wonder
2016-12-18 20:51     ` [bitcoin-dev] Python test suite failures (was Re: Planned Obsolescence) Douglas Roark
2016-12-19  8:13       ` Alice Wonder
2016-12-21 18:33         ` Marco Falke
2016-12-19  2:22     ` [bitcoin-dev] Planned Obsolescence Matt Corallo
2016-12-19  6:39       ` Btc Drak

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='CABm2gDo8DR9M9qKqhGfnRHNVrMVFGqsC-gJy4xtxT9=CQOBhgw@mail.gmail.com' \
    --to=jtimon@jtimon$(echo .)cc \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=jg@112bit$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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