Angel Leon [ARCHIVE] on Nostr: 📅 Original date posted:2016-12-15 📝 Original message:Perhaps if there were a ...
📅 Original date posted:2016-12-15
📝 Original message:Perhaps if there were a message that would nag your stdout or log output
letting you know there's a new version available, or N more versions
available and that you might be missing out on X security patches, Y
protocol improvements, depending on how far back you are, you'd be tempted
to upgrade, works for me in Ubuntu every time I log to my servers and I see
how far behind I am in terms of available updates.
Other thing done in open source projects to encourage updates, is to
automatically distribute (download) the patches and let the node operator
know an update has been downloaded for them, and let them know they're just
one step away from applying such update.
We do this for our bittorrent client. We don't ever want to do automatic
upgrades of our network, however, we want to make it painless to update.
For Bitcoin this could be done for the official binary distribution, would
not be an option for those that build from source.
On Thu, Dec 15, 2016 at 11:49 AM Jorge Timón via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Thu, Dec 15, 2016 at 4:38 AM, Juan Garavaglia via bitcoin-dev
> <bitcoin-dev at 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).
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161215/9eb2ae06/attachment.html>;
📝 Original message:Perhaps if there were a message that would nag your stdout or log output
letting you know there's a new version available, or N more versions
available and that you might be missing out on X security patches, Y
protocol improvements, depending on how far back you are, you'd be tempted
to upgrade, works for me in Ubuntu every time I log to my servers and I see
how far behind I am in terms of available updates.
Other thing done in open source projects to encourage updates, is to
automatically distribute (download) the patches and let the node operator
know an update has been downloaded for them, and let them know they're just
one step away from applying such update.
We do this for our bittorrent client. We don't ever want to do automatic
upgrades of our network, however, we want to make it painless to update.
For Bitcoin this could be done for the official binary distribution, would
not be an option for those that build from source.
On Thu, Dec 15, 2016 at 11:49 AM Jorge Timón via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Thu, Dec 15, 2016 at 4:38 AM, Juan Garavaglia via bitcoin-dev
> <bitcoin-dev at 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).
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161215/9eb2ae06/attachment.html>;