Luke-Jr [ARCHIVE] on Nostr: 📅 Original date posted:2011-09-19 🗒️ Summary of this message: Developers ...
📅 Original date posted:2011-09-19
🗒️ Summary of this message: Developers discuss the idea of creating a stable branch for Bitcoin to provide bug fixes with minimal changes and fewer risks of introducing new bugs.
📝 Original message:On Monday, September 19, 2011 8:49:08 AM Gavin Andresen wrote:
> On Sun, Sep 18, 2011 at 7:30 PM, Luke-Jr <luke at dashjr.org> wrote:
> > If we prepare the git repository + tags, would you guys be
> > willing to make the actual release builds + source, and/or post such on
> > the websites you administrate?
> > Luke and various others in #bitcoin-stable
>
> My initial reaction is no. Testing and bug-fixing is the bottleneck
> for making core bitcoin better, and maintaining two release lines
> won't make that better.
>
> I also think that until we get to a "1.0" that we can all agree is
> ready for everybody AND their grandma to use, using the word "stable"
> would be dishonest.
The problem with the current development model is that bugfixes are done
alongside improvements, and code changes *always* have the potential to
introduce new bugs, no matter how careful anyone is. So to stay on top of
bugfixes right now implies risking new bugs being introduced. What good is
getting one bug fixed, if it comes with 20 new yet-to-be-discovered bugs?
For example, 0.3.20.2 was the last version if bitcoind before people started
experiencing random (albeit rare) deadlocks. However, there have been many
bugfixes since then. Since there is no stable branch, someone who wishes to
get those bugfixes is forced to either create their own stable branch from
scratch, or risk getting all the new bugs introduced in the latest version
(most of which are unknown at this time).
On the other hand, a stable 0.4.x branch can provide people with upgrades
which they know make only the minimal changes required to fix bugs with a much
smaller risk of new bugs being introduced (not only are there fewer changes,
but bugfixes tend to also be less invasive changes). While there are arguably
still various "must-have" features missing from 0.4, having a stable branch
also allows people to maintain a stable+<feature I need> branch with greater
ease too.
Published at
2023-06-07 02:27:23Event JSON
{
"id": "25d3d40aa18f573422cf994489810dac4e6dbea25c99b632a6c0a23be781c6e7",
"pubkey": "6ac6a519b554d8ff726a301e3daec0b489f443793778feccc6ea7a536f7354f1",
"created_at": 1686104843,
"kind": 1,
"tags": [
[
"e",
"0ae916b64652df113a104fccbfbc28fa76834bc49558c45ca1a489a5c0f8c04c",
"",
"root"
],
[
"e",
"90bf5eaf6b823a92422d3a4e667cefa2afde95da1051f2ebf690e2f943dd50a1",
"",
"reply"
],
[
"p",
"c86b2a2e41d61aaf7ab7198ba65cf5a35c015f3117a71eaba5e19bb537b20051"
]
],
"content": "📅 Original date posted:2011-09-19\n🗒️ Summary of this message: Developers discuss the idea of creating a stable branch for Bitcoin to provide bug fixes with minimal changes and fewer risks of introducing new bugs.\n📝 Original message:On Monday, September 19, 2011 8:49:08 AM Gavin Andresen wrote:\n\u003e On Sun, Sep 18, 2011 at 7:30 PM, Luke-Jr \u003cluke at dashjr.org\u003e wrote:\n\u003e \u003e If we prepare the git repository + tags, would you guys be\n\u003e \u003e willing to make the actual release builds + source, and/or post such on\n\u003e \u003e the websites you administrate?\n\u003e \u003e Luke and various others in #bitcoin-stable\n\u003e \n\u003e My initial reaction is no. Testing and bug-fixing is the bottleneck\n\u003e for making core bitcoin better, and maintaining two release lines\n\u003e won't make that better.\n\u003e \n\u003e I also think that until we get to a \"1.0\" that we can all agree is\n\u003e ready for everybody AND their grandma to use, using the word \"stable\"\n\u003e would be dishonest.\n\nThe problem with the current development model is that bugfixes are done \nalongside improvements, and code changes *always* have the potential to \nintroduce new bugs, no matter how careful anyone is. So to stay on top of \nbugfixes right now implies risking new bugs being introduced. What good is \ngetting one bug fixed, if it comes with 20 new yet-to-be-discovered bugs?\n\nFor example, 0.3.20.2 was the last version if bitcoind before people started \nexperiencing random (albeit rare) deadlocks. However, there have been many \nbugfixes since then. Since there is no stable branch, someone who wishes to \nget those bugfixes is forced to either create their own stable branch from \nscratch, or risk getting all the new bugs introduced in the latest version \n(most of which are unknown at this time).\n\nOn the other hand, a stable 0.4.x branch can provide people with upgrades \nwhich they know make only the minimal changes required to fix bugs with a much \nsmaller risk of new bugs being introduced (not only are there fewer changes, \nbut bugfixes tend to also be less invasive changes). While there are arguably \nstill various \"must-have\" features missing from 0.4, having a stable branch \nalso allows people to maintain a stable+\u003cfeature I need\u003e branch with greater \nease too.",
"sig": "8bd0e0f5500512fafd36484507cfc0ba1d9e0068a1512313d16fc096e97c445f56ba18f5669aac4f936cc0f8160168d0bafc0915ec370bd1afd34f168aba49ff"
}