Published on: 2011-09-21T14:24:25+00:00
In a discussion about the development process for Bitcoin, Jeff Garzik suggests following the kernel's development process as a potential model. This involves releasing a stable version and then accepting pull requests for the next version during a specific time period. Afterward, a stabilization and bug fix period begins. The speaker agrees with this suggestion but also believes that the desire for a stable branch indicates a larger quality assurance problem. They emphasize the importance of testing and documenting procedures for code submitted via the pull button to address the issue tracker backlog.Luke-Jr raises concerns about bug fixes being done alongside improvements in the current development model. They argue that code changes always have the potential to introduce new bugs, so fixing bugs while introducing new features may result in more bugs overall. Luke-Jr suggests having a stable version and expresses their use of version 0.3.19 with modifications, believing that none of the bug fixes after this version help much and that they don't need any new features. They consider starting an unofficial stable version with their modifications and backported bug fixes.Gavin Andresen initially expresses reluctance towards maintaining two release lines for Bitcoin's core software. He believes that testing and bug fixing are the bottleneck for improving the core Bitcoin and that having two release lines wouldn't alleviate the issue. Gavin also points out the difficulty of balancing the need for bug fixes with the risks associated with introducing new code. However, he acknowledges the benefits of having a stable branch like 0.4.x, providing people with minimal changes required to fix bugs and a smaller risk of introducing new ones.Gavin Andresen proposes that bitcoin.org should become a platform for developers to exchange ideas about the direction of Bitcoin, similar to bittorrent.org. He sets up a process for proposing changes to the Bitcoin protocol, favoring long discussions over voting. Gavin suggests that this approach, modeled after Wikipedia's resolution of issues, is superior to Debian's cycling board of voting members. He believes that this change will contribute to Bitcoin's eventual success.In the discussion about creating a stable release line for Bitcoin, Gavin Andresen expresses his initial reaction as a no. He believes that testing and bug fixing are the primary bottlenecks for improving core Bitcoin. Furthermore, he mentions the challenge of providing a stable base for miners, banks, and webservices while keeping up with development. Gavin suggests putting more effort into mainlining changes and restructuring code to accommodate patches that aren't suitable for the mainline. This would encourage people to make their fixes publicly available instead of keeping them private.Luke-Jr proposes creating a git repository and tags for the development of new Bitcoin releases. However, Gavin Andresen expresses concerns about maintaining two release lines as it may slow down testing and bug fixing. He suggests that if Luke-Jr and others want to create 0.4. * releases, they can build binaries, QA test them, and release them while linking to their binaries from bitcoin.org. Gavin envisions a future where various Bitcoin implementations exist, and bitcoin.org serves as a forum for developers to discuss the direction of Bitcoin.A group of developers wants to maintain version 0.4 as a stable branch with only bug fixes. They propose naming the next mainline version after 0.4 as 0.5, allowing them to release versions like 0.4.1 and 0.4.2. They ask Gavin Andresen, Jeff Garzik, and others if they would be willing to make the actual release builds and source code available on websites they administrate. Luke and various others in #bitcoin-stable are involved in this proposal.
Updated on: 2023-08-01T02:28:43.876967+00:00