GNU Bazaar
GNU Bazaar, often abbreviated as Bazaar or invoked via the command-line toolbzr, is a distributed revision control system designed to track changes in software projects, enable efficient collaboration among developers, and manage version histories over time. Originally developed by Canonical Ltd. as Bazaar-NG, it supports both fully distributed workflows—where each user maintains a complete copy of the project repository—and centralized setups, allowing seamless integration with existing tools like Subversion or Git through plugins and foreign branch support. Written primarily in Python, Bazaar emphasizes user-friendliness with features such as lightweight branches, rich annotations for commits, and flexible transport protocols including HTTP, FTP, and SFTP for remote operations.[1][2][3]
Bazaar originated in 2004 as a fork of the GNU Arch revision control system, led by developer Martin Pool at Canonical, with the goal of creating a more accessible distributed VCS amid the rise of tools like BitKeeper and early Git prototypes. It quickly gained traction through Canonical's sponsorship, powering Ubuntu's development processes and Launchpad's code hosting platform, and was officially adopted as a GNU project in February 2008. Key milestones include the introduction of pack-based storage formats in 2006 for improved performance, monthly release cycles through 2009, and extensive plugin ecosystems that extended its capabilities to handle large-scale projects like Samba and Inkscape. The system is licensed under the GNU General Public License version 2 or later, ensuring its status as free software compatible with the GNU ecosystem.[3][4][2]
While Bazaar's development peaked in the late 2000s with a core team of five full-time contributors funded by Canonical, activity slowed significantly after 2012 as resources shifted toward other priorities, culminating in the last official release (version 2.7.0) in February 2016. In June 2025, Canonical announced the phase-out of Bazaar support on Launchpad, with repository access and hosting discontinued by December 11, 2025, reflecting its displacement by Git in modern workflows. Nonetheless, community-driven efforts persist, including the Breezy fork (brz), which continues active maintenance with Python 3 support and compatibility with Bazaar formats, and it remains in use for legacy projects valuing its Python-based extensibility and cross-platform compatibility on Linux, macOS, and Windows.[3][2][5][6][7]
History
Origins and Early Development
The development of GNU Bazaar, originally known as Bazaar-NG, began in late 2004 when Martin Pool joined Canonical Ltd. and initiated work on a new distributed version control system as a ground-up rewrite in Python, forking from the complex GNU Arch (tla).[3] Pool, along with key early contributors Robert Collins—who had previously announced the related Baz project in October 2004—and John Arbash Meinel, aimed to create a more accessible tool that addressed the usability limitations of existing systems like GNU Arch, particularly for collaborative software development in free software projects.[3][8] This effort emerged from practical needs in patch management, building on tools like the Patch Queue Manager (PQM), which Pool had developed to automate patch review and integration for Linux packaging workflows, improving efficiency over manual processes in revision control.[9] The first public pre-release, version 0.0.1, was issued on March 26, 2005, marking the initial availability of Bazaar-NG as an open-source project with a dedicated website and mailing list.[10] Written primarily in Python 2 for portability and readability, it incorporated optional Pyrex-generated C extensions to enhance performance in critical areas like diffing and packing, while maintaining a lightweight core suitable for non-technical users.[11] From its inception, Bazaar-NG emphasized ease of use through intuitive commands and flexible workflows, supporting both centralized server-based operations and fully decentralized peer-to-peer collaboration without requiring a dedicated server infrastructure.[3] Early iterations in 2005 and 2006 focused on core functionality and network efficiency, including the addition of smart server support for optimized remote operations and HTTP transport to enable seamless access over standard web protocols.[3] These enhancements, developed during community sprints such as the first Bazaar event in London in May 2006, allowed for rapid prototyping and testing, with projects like Samba evaluating the tool via Google Summer of Code in 2005 despite initial challenges in repository conversion.[3] By October 2005, the stable 0.1 release solidified these foundations, incorporating community patches and establishing Bazaar-NG as a viable alternative for distributed revision control.[8]GNU Adoption and Canonical Sponsorship
In February 2008, Bazaar was officially accepted as a GNU project following approval from Richard Stallman, the founder of the GNU Project, leading to its renaming as GNU Bazaar to reflect its alignment with GNU's free software principles.[12] This endorsement marked a significant institutional milestone, integrating Bazaar into the GNU ecosystem and emphasizing its commitment to open-source development tools. Canonical's sponsorship of Bazaar commenced in 2006, providing financial and resource support that enabled the hiring of full-time developers, including original creator Martin Pool, to accelerate its maturation.[3] By 2007, Bazaar was integrated into Canonical's Launchpad platform, which served as the primary development environment for Ubuntu, facilitating seamless version control for the distribution's codebase.[13] This backing transformed Bazaar from an independent project into a professionally maintained tool, with Canonical contributing infrastructure and expertise to enhance its reliability for large-scale collaborative workflows.[14] Key milestones under this sponsorship included the release of Bazaar 1.0 on December 14, 2007, which introduced stable features for distributed revision control and was positioned as a robust alternative to centralized systems.[14] In 2008, Ubuntu adopted Bazaar as its default version control system, streamlining development processes across the project and encouraging broader community participation through accessible branching and merging.[3][15] These advancements solidified Bazaar's role in Ubuntu's ecosystem, with Canonical's investment driving improvements in usability and performance tailored to Linux distribution workflows.[16] Canonical further developed Launchpad-specific features for Bazaar, including automated code import services that converted repositories from CVS and Subversion into Bazaar format, enabling legacy projects to migrate without data loss.[17] Shared repository hosting on Launchpad optimized storage and collaboration by allowing multiple branches to share common history data, reducing redundancy in team-based development.[18] These enhancements, built directly into Launchpad's infrastructure, supported efficient code review, bug fixing, and integration for Ubuntu maintainers.[19] Internally, Canonical relied on Bazaar for Ubuntu packaging workflows and bug tracking through Launchpad until the mid-2010s, where it handled source code management, patch application, and issue resolution for the distribution's vast repository.[20] This prolonged use underscored Bazaar's practical utility in a high-volume environment, with tools like thebzr command-line interface integrated into daily operations for maintaining package integrity and tracking changes across releases. By fostering a unified system for development and quality assurance, Canonical's adoption helped propagate Bazaar's methodologies throughout the Ubuntu community.[21]
Peak Usage and Decline
Bazaar reached its peak popularity between 2008 and 2012, during which time Launchpad hosted around 10,000 projects utilizing its code hosting features integrated with Bazaar branches.[22] As the default version control system for Ubuntu development, Bazaar managed source code for numerous packages, facilitating collaborative workflows across the distribution's ecosystem.[23] Notable adoptions during this period included Mozilla's use of Bazaar for Bugzilla development, enhancing its distributed revision control capabilities starting around 2009.[24] Similarly, GNU Emacs transitioned its source code management to Bazaar in late 2009, integrating it into the project's development processes alongside other GNU tools.[25] The decline of Bazaar's usage began in the mid-2010s, largely due to the rising dominance of Git, which gained traction from its 2005 inception as the Linux kernel's primary system and its superior performance in handling large-scale repositories.[26] Bazaar's reliance on Python contributed to slower execution on expansive projects compared to Git's optimized C implementation, exacerbating performance gaps in high-volume environments.[27] By 2013, Ubuntu developers increasingly adopted a hybrid approach, incorporating Git for certain workflows while retaining Bazaar for legacy package management, amid growing community feedback on unresolved bugs and delayed maintenance.[28] The release of Bazaar 2.6 in August 2013 marked the final major update, with subsequent development shifting to minimal bug fixes. User migrations to Git accelerated after 2015, as prominent projects like GNU Emacs completed their transitions, further diminishing Bazaar's active adoption.[29]Retirement Announcement
On June 4, 2025, Canonical announced via Ubuntu Discourse the phasing out of Bazaar code hosting on Launchpad, marking the end of support for the version control system on the platform.[5] This decision aligns with broader trends of declining usage, as Bazaar peaked in adoption around 2015 and has since seen minimal activity.[5] The timeline for discontinuation includes two key phases. First, imports from CVS and Subversion to Bazaar branches were deprecated, with no new configurations accepted after September 18, 2025, and all existing imports shut down by October 1, 2025.[30] Second, full shutdown of the Bazaar backend occurred on December 11, 2025, delayed from an initial target of September 1, 2025, to allow additional migration time; this ended all repository access, pushing, and browsing capabilities.[31][5] Canonical cited several reasons for the retirement, including Bazaar's low current usage after peaking a decade earlier, the ongoing maintenance burden of supporting an outdated system, and the widespread industry shift to Git as the dominant version control tool.[5] The last official release of GNU Bazaar, version 2.7.0, was on February 15, 2016, with no active maintenance from the GNU project since then.[1] This change has no impact on internal Ubuntu development, which transitioned to Git-based workflows years prior.[5] For existing users, Canonical recommended migrating repositories to Git using available tools and guides, or adopting the Breezy fork for continued local Bazaar usage.[5] Post-shutdown, Launchpad archives Bazaar repositories for download but provides no further support or hosting functionality.[31]Design Principles
Distributed Revision Control Model
GNU Bazaar operates on a distributed revision control model that emphasizes decentralization, allowing each user to maintain a complete, independent copy of the project repository. This design enables developers to work offline, commit changes locally, and synchronize with others as needed, without relying on a mandatory central authority. Revisions in Bazaar are immutable snapshots of the project state, each uniquely identified by a deterministic revision ID—such as[email protected]—which incorporates details like the committer's identity, timestamp, and a sequence number to ensure global uniqueness and traceability across repositories.[32]
The system's architecture supports a hybrid approach, blending fully decentralized operations with client-server capabilities for efficient collaboration. In standalone mode, users manage local repositories entirely on their machines, fostering ad-hoc teamwork through peer-to-peer exchanges of changes. For networked environments, Bazaar employs "smart servers" accessible via protocols like bzr:// or bzr+ssh://, which handle server-side optimizations such as autopacking revisions and batching data transfers into efficient chunks (e.g., approximately 5MB per request) to minimize bandwidth usage without requiring users to clone entire histories. This hybrid flexibility accommodates both solo developers and large teams, scaling from local experimentation to distributed, multi-site development scenarios.[32][1]
Central to Bazaar's model are several key concepts that enhance usability and efficiency. A working tree represents a local, editable directory of project files, directly associated with a branch's history stored in the .bzr subdirectory, allowing seamless tracking of modifications. Lightweight checkouts, created with the --lightweight option, provide a space-efficient alternative by linking to a remote branch without duplicating its full history locally, ideal for quick access to shared codebases. Bound branches further streamline workflows by tying a local branch to a remote "master" location, automatically propagating commits to the central repository upon binding, which supports structured team synchronization while preserving decentralization. These elements collectively enable users to perform pushes and pulls effortlessly, even in disconnected settings, prioritizing accessibility over rigid hierarchies.[32]
A distinctive feature of Bazaar's distributed model is its shared repository mode, designed for collaborative environments where multiple branches coexist. In this setup, initiated with bzr init-repo --no-trees, a single repository stores the common revision history for several branches, significantly reducing disk space requirements—particularly beneficial for large projects or repositories with numerous related branches. This optimization allows teams to maintain a centralized pool of shared data while each branch operates independently, striking a balance between resource efficiency and the autonomy inherent to distributed control. Overall, the model underscores Bazaar's philosophy of user-friendliness, eliminating the need for administrative servers and empowering developers with intuitive tools for offline innovation and flexible integration.[32]
Branching and Merging Mechanisms
Bazaar implements branching through thebzr branch command, which creates a new, independent branch as a lightweight copy of an existing one, sharing underlying repository data to avoid full duplication and enabling efficient local development without network access.[33] This approach leverages the distributed revision control model, where branches can reference shared history, facilitating rapid creation of feature or topic branches for parallel work.[33]
Merging in Bazaar utilizes a three-way merge algorithm that identifies a common ancestor via revision graphs, comparing changes from two branches against this base to integrate modifications automatically where possible.[34] The algorithm follows defined rules for resolution: if the ancestor (A) has value x, and the two branches (B and C) agree on x or y, it adopts that value; discrepancies result in conflicts for manual intervention.[34] Bazaar supports cherrypicking of specific revisions and employs weave-based history reconstruction to preserve accurate ancestry during non-linear merges, ensuring high-quality tracking of prior integrations to avoid redundant work.[34]
When the three-way merge encounters irreconcilable changes, Bazaar handles conflicts by inserting conflict markers into affected files and generating auxiliary files—such as filename.BASE (ancestor), filename.THIS (current branch), and filename.OTHER (incoming branch)—for reference during resolution.[35] Users manually edit the files to resolve issues, removing markers, and then invoke bzr resolve to mark the conflict as addressed, which cleans up auxiliary files and updates the branch status.[35] For complex cases like criss-cross merges, the bzr remerge --weave option applies an alternative weave algorithm to attempt resolution.[35]
Advanced features include nested trees, which enable stacked branches where a branch references the history of a base branch for reduced storage needs, particularly useful in large projects or when splitting subcomponents like external libraries.[36] [33] Merge directives provide a mechanism for workflows involving email or patches, generating structured files via bzr send that encapsulate revision bundles and instructions, allowing recipients to apply changes with bzr merge without requiring full branch access.[33]
A key innovation in Bazaar's design is the weave format for delta storage, which interleaves changes across revisions in a single structure, supporting efficient reconstruction of file states and enabling robust handling of non-linear histories during branching and merging operations.[37] This format, introduced early in development, allows Bazaar to perform merges with precise ancestry awareness, minimizing conflicts in divergent branches compared to linear storage approaches.[38]
Storage Formats and Protocols
Bazaar employs a native storage format that evolved to prioritize efficiency in handling large repositories. The initial formats used full file texts for each revision, but by 2006, Bazaar transitioned to the knit format, which stored file histories as sequences of deltas rather than complete files, reducing redundancy. This was further refined in 2007 with the introduction of pack-based storage, where knits for file texts, inventories, and revisions are grouped into compressed pack files, improving both disk usage and access speeds for operations like branching and merging.[3][39] Revision data in Bazaar is organized around inventory trees, which represent the complete state of a project's files and directories at each revision, using radix trees for efficient storage and querying. File contents are stored using text deltas, capturing only changes between versions to minimize space, with support for binary files via full-text storage when deltas are inefficient. Cryptographic signatures for revisions are optional and integrated via GnuPG, allowing users to sign commits for authenticity verification during pushes, pulls, or merges.[40][41] For network protocols, Bazaar supports SFTP for secure file transfers over SSH, enabling read and write access without a dedicated server. It also uses HTTP and HTTPS with a "smart" protocol that allows efficient partial data fetches, reducing bandwidth for operations like history queries or incremental updates. Additionally, a custom Bazaar protocol operates over TCP (via bzr://), providing optimized, bidirectional communication when a smart server is configured, which is particularly useful for high-performance collaborative workflows.[42][43] Bazaar's disk formats maintain backward compatibility, ensuring newer versions can read and write older repositories without data loss or conversion. This multi-format support extends to interoperability with foreign version control systems, such as reading and writing Git repositories through the bzr-git plugin, introduced around 2008, and mirroring Subversion branches via the bzr-svn plugin, facilitating hybrid environments.[44][3][45] The evolution from the knit format to packs addressed key performance bottlenecks, achieving better compression ratios and faster retrieval times for revision histories, as packs enable batched delta resolution and reduced I/O overhead compared to scattered knit files.[3]Key Features
Command-Line Interface and Workflows
GNU Bazaar primarily utilizes a command-line interface (CLI) through thebzr executable, which provides a straightforward and extensible way for users to manage version-controlled projects. The CLI is designed for efficiency, allowing developers to initialize repositories, track changes, and synchronize branches with minimal commands. This interface emphasizes simplicity while supporting advanced distributed workflows, making it suitable for both individual and collaborative development.[46]
Core commands form the foundation of user interactions in Bazaar. To set up a new repository, users run bzr init in a target directory, which creates a local branch with its own history and metadata. Adding files for tracking is done via bzr add, followed by bzr commit to record changes with a descriptive message, creating a new revision in the branch's history. Synchronization between branches is handled by bzr push to send local changes to a remote location, bzr pull to fetch and integrate remote changes into the local branch, and bzr update to refresh the working tree with the latest revisions from the bound branch. These commands enable seamless management of project evolution without requiring a central server.[46][47][48]
Bazaar supports flexible workflows tailored to different team structures. In a centralized workflow, developers push changes directly to a mainline branch on a shared server, mimicking traditional systems like Subversion, where bzr push integrates commits to the authoritative repository. Distributed peer-to-peer workflows allow independent branches to exchange revisions via bzr pull and bzr push without a central hub, fostering offline development and selective merging. For team collaboration, shared repositories optimize storage by housing multiple branches in one location, reducing redundancy while enabling efficient access; users can create such repositories with bzr init --shared and bind working trees to them. Additionally, Bazaar includes shelving functionality via bzr shelve to temporarily store uncommitted changes aside, allowing users to switch tasks or clean the working tree without losing work—unshelving restores them with bzr unshelve.[49][50][51][52]
The CLI is extensible through Python plugins, which integrate seamlessly by placing scripts in the ~/.bazaar/plugins directory. Plugins can add new commands or modify existing ones, such as bzr-xmloutput, which extends bzr log, bzr status, and others with an --xml option for machine-readable output in development automation. Another example is bzr-grep, which enables searching file contents and revision history for patterns, aiding in code maintenance and auditing. This modularity allows customization without altering the core tool.[53][54][55]
While the CLI remains the primary interface, graphical options like QBzr—a Qt-based frontend providing dialogs for core commands—and Bazaar Explorer, a desktop application for browsing branches and visualizing history, offer alternatives for users preferring visual tools; however, these build upon the underlying bzr commands.[56][57]
Best practices in Bazaar emphasize proper configuration and history management. Users should set their identity early with bzr whoami "Full Name <[email protected]>" to ensure accurate attribution in commits, as this information is embedded in revisions. For reviewing project history, bzr log displays a chronological list of changesets, including authors, dates, and messages; options like --line or --tree enhance visualization for branching insights. These habits promote clear collaboration and traceability in workflows.[50][58]
Integration Capabilities
Bazaar provides robust integration with various integrated development environments (IDEs) through dedicated plugins and hooks, enhancing developer workflows by embedding version control operations directly into editing sessions. For Eclipse, the bzr-eclipse plugin enables seamless interaction with Bazaar repositories, allowing users to perform commits, updates, and branch management from within the IDE, leveraging Launchpad's API for additional functionality such as branch synchronization.[59] Similarly, Vim users can employ the bzr-vim plugin, which integrates Bazaar commands into the editor via the VCSCommand framework, supporting actions like diff viewing and status checks without leaving the Vim interface.[60] Although no native plugin exists for Visual Studio, integration is achievable through external tools configuration, where Bazaar commands can be mapped to Visual Studio's menu system for tasks such as committing changes or viewing logs.[61] Additionally, Bazaar's hook system supports pre-commit checks, permitting custom scripts to validate code quality, run linters, or enforce policies before changes are recorded, configurable via the bzrlib API or simple Python functions.[62] In continuous integration and continuous deployment (CI/CD) pipelines, Bazaar integrates effectively with tools like Jenkins and Launchpad's build services. The official Bazaar plugin for Jenkins (formerly Hudson) facilitates automated builds by polling repositories, executing bzr commands during jobs, and generating changelogs from commit histories, requiring only the bzr binary on the build agent.[63] Launchpad's integration extends this by automating testing and packaging for Bazaar branches associated with projects; for instance, when changes are proposed via branches, Launchpad triggers builds in personal package archives (PPAs), though this service is scheduled for discontinuation on December 11, 2025. However, as of June 2025, Canonical announced the phase-out of Bazaar support on Launchpad, with discontinuation of repository hosting and related services by December 11, 2025, encouraging migration to Git.[64][65] Bazaar supports interoperability with foreign version control systems (VCS) through specialized tools for migration and bidirectional operations. The bzr fast-import command imports history from systems like Git, Subversion, CVS, Mercurial, Darcs, and Perforce using a standardized stream format, enabling efficient one-way transfers while preserving metadata such as authors and revisions.[66] For ongoing collaboration, the bzr-svn plugin provides bidirectional bridges to Subversion repositories, allowing Bazaar users to push changes back to SVN trunks or pull updates seamlessly, treating SVN as a native-like backend without full repository conversion.[45] Scripting and automation are facilitated by Bazaar's Python API, known as bzrlib, which exposes core functionality for building custom tools and integrating into larger workflows. Developers can use bzrlib to manipulate branches, query histories, or automate merges programmatically, with the library distributed as python-bzrlib in Ubuntu repositories. In Ubuntu's Debian packaging ecosystem, bzrlib formerly powered tools like bzr-builddeb, which automates the creation of source and binary packages from Bazaar branches, handling tasks such as generating changelogs, applying patches, and building .deb files directly from upstream sources.[67] For web-based repository management, Bazaar employs Loggerhead as its primary interface, offering a browser-accessible viewer for exploring branch histories, annotating files, and reviewing diffs without local installation. Loggerhead integrates natively with Launchpad, where it serves as the frontend for hosted Bazaar projects, enabling public browsing, subscription to changes, and integration with bug trackers for contextual code reviews.[68][69]Cross-Platform Support and Performance
GNU Bazaar provides native support for Linux distributions, where it is primarily developed and optimized, as well as Windows and macOS through Python-based installations.[1] On Linux systems such as Ubuntu, Debian, SUSE, Fedora, and Gentoo, Bazaar integrates seamlessly via standard package managers.[1] For Windows, it runs via the MSYS environment to provide Unix-like compatibility, while macOS support leverages the system's Python runtime.[70] Additional packages exist for FreeBSD, Solaris, and other Unix-like systems, ensuring broad accessibility across diverse operating environments.[70] Bazaar requires Python 2.7 for operation, a dependency that became unmaintained after Python 2's end-of-life in January 2020, limiting long-term viability without community forks.[71] The original implementation lacks native Python 3 support, though forks like Breezy address this by porting to Python 3 while maintaining compatibility. In terms of performance, Bazaar excels with small-to-medium repositories, typically those ranging from 10 to 100 MB, where operations like commits and updates complete efficiently due to its lightweight design.[3] However, it exhibits slowdowns on large histories exceeding several gigabytes, attributable to Python's interpretive overhead and the system's reliance on object-oriented history storage.[3] The introduction of pack formats in Bazaar 2.0 significantly enhanced I/O efficiency, yielding 2-5x improvements in read and write speeds for repository operations in independent benchmarks.[72] Key optimizations include lazy loading of revision history, which defers full graph construction until necessary, reducing initial startup times and memory footprint during common workflows.[73] The smart protocol further mitigates network demands by compressing and selectively transmitting changesets, achieving 50-70% bandwidth savings during pull operations over HTTP or SSH compared to naive transfers.[74] Limitations persist, particularly higher memory consumption on Windows due to Python's garbage collection and filesystem interactions, often requiring 20-50% more RAM than on Linux for equivalent tasks.[3] Bazaar's cross-platform test suite, utilizing Python's unittest framework, achieves approximately 90% code coverage, ensuring consistent behavior across supported operating systems through automated regression testing.[3] Historical benchmarks demonstrate Bazaar's merge operations outperforming Subversion by about 20% in time for integrating parallel branches in medium-sized projects.[75] These traits stem from its storage efficiency, which prioritizes readable, pack-based inventories for balanced resource use.[73]Development and Maintenance
Release History
Bazaar development began with the release of version 0.1 in October 2005, which introduced basic branching and distributed revision control capabilities.[76] The project was hosted on Launchpad, Canonical's collaborative platform, where bugs were tracked using its integrated bug reporting system.[2] Version 1.0 arrived on December 14, 2007, providing a stable command-line interface suitable for everyday use in software development workflows.[77] This milestone solidified Bazaar's core functionality, emphasizing ease of use for both local and networked operations. Subsequent major releases built on this foundation. Bazaar 2.0, released in October 2009, established the 2a repository format as the default and enhanced the smart server protocol for improved performance in client-server interactions.[78] In August 2010, version 2.2 introduced support for Git-compatible formats, enabling better interoperability with other version control systems through plugins like bzr-git.[79] The 2.5 series, starting with 2.5.0 in March 2012, focused on performance optimizations, including tweaks for handling large repositories more efficiently.[80] The final official release, 2.7.0, came on February 15, 2016, incorporating fixes for compatibility with Python 2.7 and marking the end of active development under Canonical's primary sponsorship.[1] Following Canonical's reduction in funding around 2012, maintenance shifted to a volunteer-driven model.[3] Over the project's lifespan, more than 100 minor versions were released, with peak development activity occurring between 2008 and 2012, when monthly contributions often exceeded 10 active participants.[81]Community Contributions and Forks
After the last official release of GNU Bazaar in 2016, community-driven maintenance shifted primarily to forks and select plugins, as active development on the original project ceased.[2] Launchpad continued to host the Bazaar codebase, allowing limited bug reporting, but no significant fixes or updates were applied post-2016.[2] Plugins such as bzrtools, which provided utilities for Bazaar workflows, saw historical maintenance on Launchpad but lacked ongoing updates by 2025.[82] The most prominent community effort is the Breezy fork, initiated in 2017 by Jelmer Vernooij to sustain and modernize the project.[83] Rebranded as brz, it completed a full migration from Python 2 to Python 3, enabling compatibility with contemporary Python environments.[6] Breezy maintains backwards compatibility with Bazaar's disk formats and protocols, allowing seamless access to existing repositories.[6] It also introduces native support for Git formats, facilitating interoperability between the two systems.[6] Breezy has seen steady releases continuing into 2025, including version 3.3.17 in October 2025, with ongoing development hosted on both GitHub and Launchpad.[84] Adoption includes integration into Fedora, where it replaced the original bzr package in 2020 (Fedora 32) to ensure continued support for Bazaar repositories without disruption.[85] The fork provides command-line tools viabrz (symlinked as bzr for compatibility) and preserves core APIs for user workflows.[85]
Other community contributions include minor plugins like bzr-loom, which extends Bazaar for advanced weaving of multiple patches in a single branch, though it remains a specialized tool without broad evolution.[86] A lesser-known effort is the bazaar3 fork by the bazaar-community, aimed at revitalizing the project, but it has seen limited activity compared to Breezy.[87] No major competing forks have emerged beyond Breezy.
As of 2025, Breezy maintains an active development cycle with contributions from a small team, focusing on bug fixes and enhancements.[6] Meanwhile, the official GNU Bazaar page on gnu.org remains unchanged from its pre-2016 state, promoting the original tool without updates, while Canonical's 2025 retirement of Bazaar hosting on Launchpad explicitly recommends migrating repositories to Git.[1][88]