Canonical stopt met codebeheersysteem Bazaar

Canonical stopt met Git-alternatief Bazaar. Volgens de Ubuntu-ontwikkelaar is dat systeem voor codebeheer al jaren niet meer relevant en is Git een beter alternatief. Ook de frontend voor Bazaar stopt ermee.

Canonical waarschuwt gebruikers dat het per 1 september van dit jaar definitief stopt met Bazaar. Vanaf dat moment zijn repo's die daar gehost worden niet meer beschikbaar. Gebruikers moeten hun repo's naar Git overzetten, waarvoor Canonical een stappenplan heeft beschreven.

Loggerhead werkt per direct niet meer. Dat is de frontend van Bazaar waarmee gebruikers code in een gebruikersinterface konden bekijken. Dat kon in browsers via Launchpad, het codehostingplatform van Canonical. Het blijft wel mogelijk pull- en pushrequests te doen en code te mergen, maar niet meer via de frontend.

Volgens Canonical is Bazaar niet langer relevant. Dat het bedrijf ermee stopt, komt niet als verrassing: Bazaars laatste release was bijna tien jaar geleden, in 2016. Sindsdien is er de fork Breezy opgekomen die nog wel wordt onderhouden, maar voor Bazaar zelf is dat niet het geval. Canonical zegt verder dat Bazaar niet meer relevant is nu er modernere alternatieven zijn, waarvan Git het meest gebruikt is. Volgens het bedrijf werd ook de frontend vrijwel niet meer gebruikt. "In de logs is te zien dat er vrijwel geen verzoeken meer komen van legitieme gebruikers, maar dat bijna al het verkeer afkomstig is van scrapers", zegt Canonical.

Canonical Bazaar

Door Tijs Hofmans

Nieuwscoördinator

06-06-2025 • 07:28

50

Submitter: TheVivaldi

Reacties (50)

50
50
29
1
0
13
Wijzig sortering
Jammer, maar ik vraag me af: wat was de USP van Bazaar tegenover andere version control systems? Git bestaat al een tijdje en is in essentie niet veel veranderd. Was er iets waarin Bazaar beter was dan git?
Git, Bazaar, en Mercurial zijn allemaal rond dezelfde tijd gemaakt. Van de 3 is Git de meeste ingewikkelde in gebruik zowel in gebruikersinteractie als het systeem opzetten. Mercurial was het meest gebruiksvriendelijke.
Maar slechts de tool zelf is niet genoeg, de support en integratie (e.g. IDE support) er omheen is heel belangrijk voor de adoptie door gebruikers. En daar verliest Bazaar van de twee andere. Mercurial is ondertussen ook steeds meer gebruikers aan het verliezen, omdat Git de defacto standaard geworden is. En ondertussen is Git al zeer goed te gebruiken op verschillende systemen (alhoewel Windows altijd een probleem blijft) en ook aan de gebruiksvriendelijkheid is enorm gewerkt (alhoewel de gedrochten van vroeger blijven bestaan).

Dus was er een goede reden om Bazaar te gebruiken (in de afgelopen 10 jaar): niet echt
Goede reactie, alleen jammer van de opmerking over Windows ;) Ik hoor van alles bij bedrijven waar ik kom, of binnen het bedrijf waar ik zelf werk en tevens mijn eigen ervaring, maar nog nooit heb ik iemand gehoord die problemen heeft met GIT op Windows, waardoor ik denk dat het wel mee valt allemaal, in ieder geval bij software ontwikkelaars. Maargoed ik heb ook geen statistieken oid opgezocht, dus wie weet het ik gewoon geluk gehad :)

[Reactie gewijzigd door WhistlerNL op 6 juni 2025 10:37]

Git op Windows werkt prima, maar er zitten absoluut nukken in.

De belangrijkste zijn hoe er met paden en hoofdlettergevoeligheid wordt omgegaan. Als je met Windows en Linux/macOS in dezelfde repositories werkt dan kom je snel problemen tegen. Bijvoorbeeld; een collega voegt een folder toe “Folder2”. Jij op Linux vindt dat niks, en maakt er “folder2” van. Deze change komt niet terug bij de Windows clients, als je een pull from remote doet dan blijft je lokale versie met de oorspronkelijke Hoofdletter. Dit levert geregeld problemen op bij ons, omdat mensen dan deployment scripts maken die uitgevoerd worden onder Linux, welke dan niet kloppen omdat de relatieve paden niet overeenkomen (Linux is hoofdlettergevoelig en folder2 en Folder2 zijn verschillende dingen).

Als je echter alleen met Windows clients werkt, dan is er niks/niet zo veel aan de hand.

Oh en symlinks, altijd lastig natuurlijk maar dat is meer een algemeen ding denk ik :)
Ik heb vaak genoeg een folder rename doorgevoerd gekregen op Windows. Als iemand anders de rename heeft gedaan werkt dat volgens mij gewoon prima. In de Git change log staat dat de file / folder renamed moet worden dus Git doet dat.

Als je zelf de rename doet dan werkt dat inderdaad niet direct. Git heeft vaak niet door dat er een rename is. Ik heb daar gelukkig al een truuk op gevonden: rename eerst van "Folder2" naar "Folder2-1" (of iets anders dat heel anders is), rename dan nog een keer naar "folder2". Let wel op dat beide renames door Git worden gezien; ik gebruik vaak "git mv" in Git Bash.
Maar wat je nu omschrijft is natuurlijk een Windows/NTFS probleem, niet een git probleem.

*edit* effe opgezocht, is blijkbaar een Windows probleem en niet een NTFS probleem hehe

[Reactie gewijzigd door noskill op 7 juni 2025 17:48]

Windows is problematisch omdat het een buitenbeentje is betreft git extensies en hooks. Op Windows hebben deze altijd speciale aandacht nodig. Dit heeft allemaal te maken met de beperkte shell scripting mogelijkheden op Windows, en in sommige gevallen significante environment verschillen.

Voor simpel git gebruikt zal je weinig merken op Windows tegenwoordig. Zeker als je je git acties via een IDE of GUI doet.
Vroeger merkte je dat wel toen het nog msysgit was. Je kreeg duidelijk vaker met bugs te maken op Windows. Sinds git for Windows is daar geen sprake meer van.
Gebruik git al mijn hele carrière (10 jaar) op Windows en het is echt geen enkel probleem. Ik denk dat deze info wat outdated is.
In omgevingen met ontwikkelaars op Windows en op Linux/Mac blijven line endings gedoe, zeker als je niet wilt dat git al je bestanden automatisch 'fixt'.
Dat heeft eigenlijk weinig met git te maken en git fixed dat alleen automatisch als je dat zo instelt. Heb er ook geen problemen mee terwijl we wel naast Windows ook Linux gebruiken (bijv wsl of de build server)
Ik ging even reageren dat volgens het artikel bazaar uit 2016 stamt wat ver voorbij de release van zowel git en mercurial zit, maar blijkt om een fout in het artikel te zijn. Alle 3 van 2005, recentste versie van bzr is van 2016. @TijsZonderH misschien toch een edit waard?

Lijkt vooral dat ik nog moet wakker worden!

[Reactie gewijzigd door JeroenED op 6 juni 2025 10:33]

Zover ik weet is GIT ontworpen voor het linux filesystem en was het voor windows eigenlijk niet geschikt. Mercurial was daarom beter, ik gebruike lang gelenden TortoiseHG
In de tijd van CVS en SVN had het misschien zijn voordelen ten opzichte daarvan. Zoals ze zelf al zeggen, git is beter.

Mijn ervaring met source-control is dat de meeste, vooral de commerciële, niet schalen. In het begin lijkt het allemaal prachtig en werken alle nifty features. Maar zodra een bedrijf er een paar miljoen regels code in heeft, beginnen ze bijna allemaal te kraken en steunen. En dan duurt het ineens 2 uur om een checkout te doen, of valt de server om de haverklap om, of gebeuren er onverklaarbare dingen, of je moet een of andere obscure oude Java runtime opduikelen om nog te kunnen werken...

Mijn advies is zonder uitzondering: Gebruik git. Die is ook niet zonder nukken, maar die schaalt tenminste goed. Er zijn goede native clients voor alle platformen.
Perforce en SVN schalen ook wel. Daar doe je je engineers geen plezier mee, maar mocht je een gecentralizeerd systeem nodig hebben dan is dat vaak wel een noodzaak.
Volgens mij was het vooral voor minder technische gebruikers gemakkelijker in gebruik. Het branching model werkt met mappen in plaats van refs, waardoor het transparanter is voor de eindgebruiker en branches gewoon als aparte directories worden weergegeven. Dit maakt het concept van parallelle versies makkelijker te begrijpen en te beheren, zonder dat je hoeft te snappen hoe staging of interne referenties in Git precies werken.

Daarnaast ondersteunde Bazaar zowel centrale als gedistribueerde workflows zonder extra tooling of configuratie. Je kon dus gewoon een centrale server gebruiken zoals bij Subversion, of lokaal werken zoals bij Git, beide opties werkten out of the box.

Ook qua foutmeldingen en commando’s was Bazaar vriendelijker: de interface was consistenter en beter leesbaar, wat het geschikt maakte voor minder technische teams of open source projecten met veel incidentele bijdragers.
Voor mij was een belangrijke USP dat bazaar ook metadata meenam, en op een goede manier met naamswijzigingen van bestanden omgaat. Dat eerste vereist een git extensie, en het tweede is hit and mis in git. Ik heb nu een 22GB bzr repo die het nog prima doet (sinds 2008), dus de conversie naar git met behoud van historie wordt een nachtmerrie. Misschien dat ik een head-only migratie ga doen, maar nu nog niet.
Welke metadata heb je het dan over?
En welke problemen loop jij tegenaan met Git als je bestanden van naam wijzigt (door middel van "git mv" neem ik aan, aangezien dat de correcte methode is)

Ik herken deze problemen namelijk helemaal niet in Git.
Wat er veranderd is, is dat de hosting kosten zijn gestegen door AI scraper bots.
Ik lees bij veel code-hosters (o.a. Gitea, Codeberg) dat die alle duur-om-renderen pagina's (blame) spammen met botnets. Dan gaat je cloud Computing rekening door Het dak
Mja niet zo heel bijzonder nieuws, maar toch is het jammer dat er niet wat meer concurrentie is voor Git momenteel. Ik vind het nog steeds vreemd dat het blijkbaar niemand lukt om daar een goede concurrent tegenover te zetten. Al is het maar voor andere use cases. Voor bv documentbeheer vind ik het nog steeds ruk. En je kunt niet tegelijk aan bestanden werken bv. Vooral voor niet-programmeurs vind ik het niet geschikt. En tuurlijk, het is ook weer niet zo heel moeilijk om te leren, maar ik heb altijd het idee gehad dat het makkelijker moet kunnen.
Het gelijktijdig aan bestanden werken lijkt mij een volledig ecosysteem te vereisen dat daar op toegespitst is, en dat bestaat: SharePoint in combinatie met MS Office bijvoorbeeld. En ik vermoed dat Google's tegenhanger het ook kan, al zit je dan wel enkel in de browser te werken, maar dat moet vandaag de dag voor de meeste mensen ook geen showstopper zijn.

Maar Git is ook geen DMS, het is source control, het is bedoeld om veilig samen aan code te kunnen werken en streeft ernaar om conflicten te voorkomen, dan wil je net niet met 2 in hetzelfde bestand aan het werken zijn want het mergen van conflicten is niet altijd even eenvoudig.

En een goede concurent in source control zal het altijd zeer moeilijk hebben, want je gaat echt iets nieuws moeten toevoegen om mensen te overtuigen over te stappen, en dat terwijl Git net enorm volledig is in wat het kan. Vergeet niet dat Git net ontstaan is doordat Linux niet langer een commercieel systeem mocht gebruiken, iets wat Bitkeeper zich achteraf ongetwijfeld beklaagd heeft net omdat Git heel de source control wereld in essentie heeft overgenomen.
Mja Sharepoint kan, maar dan moet je je in het MS ecosysteem inkopen en MS diensten gebruiken.

Maar het feit dat er geen concurrentie is op dat vlak, vind ik nog steeds vreemd want de usecase is er wel gewoon en de kosten van MS zijn gewoon heel hoog.

Wellicht dat er met de AI hype nog wat alternatieven ontstaan, zodat meerdere agents tegelijk kunnen werken, maar we gaan het zien.
Git is juist van de grond af ontworpen om met heel veel mensen aan dezelfde code te werken. En dat gedecentraliseerd. En daar blinkt het juist in uit.

Leuk dat je in sharepoint met 3 man in een word document kan gaan zitten frotten, maar dat is een heel andere usecase.

Overigens, als je opmaak en inhoud zou scheiden (zoals met Latex of Sphinx) dan kun je die wel met een gewoon versiebeheer system bewerken en beheren.

Veel bedrijven (het mijne ook) zijn nou eenmaal verliefd op MS en gooien met plezier bakken met geld naar MS terwijl de ontwikkelaars steen en been klagen en veel liever met open standaarden zouden werken.
Blijf SharePoint een gedrocht vinden dat bij menig bedrijf maar niet lekker lijkt te werken. Ook dat velen het als een Intranet gebruiken, blijft een onoverzichtelijk gedrocht. Teams blijft ook vaak terugvallen op...SharePoint.
Waarom is het jammer?
Wat is het nut om resources op te splitsen, want dan heb je met 2 systemen en 1000 man uur dus maar voor 500 uur verbeterd.

Terwijl met een Open source systeem zoals GIT gaan de 1000 uur volledig in het verbeteren van het systeem.
Hierbij is het community-driven waardoor iedereen suggesties kan voorstellen.
Wat wil je dat er gaat concurreren? Git op zich zelf zie ik als een protocol dat meerdere implementaties heeft. En voor zover ik begrijp is het een open protocol waarvoor iedereen zelf een implementatie kan maken.

Als je het over gitlab of github en dergelijke hebt: Daar kan je met alle git tools bij. Het zijn hier en daar wat speciale gevallen die verschil maken, daarvoor hebben ze wel iets van een eigen web interface of zo.

En over document beheer: Zolang dat ascii gebaseerde documenten zijn gaat dat heel goed in git. De meeste sourcecode is ascii. Maar als je het hebt over applicatie specifieke binaire formaten, dan gaat het nat, daar is git niet voor gemaakt.

Misschien is er ergens een groep bezig om een interface te maken voor html, xml en open document formaten.
de echte cool kids gebruiken nu Jujutsu vcs.
(ik ben ook een cool kid).

Na meer dan 15 jaar intensief git gebruikt te hebben ben ik over. Qua storage is het volledig git compatible maar qua UX is het een stuk simpeler (terwijl je er misschien wel meer mee kunt qua workflows). En simpel=goed.

https://kubamartin.com/po...ction-to-the-jujutsu-vcs/

https://steveklabnik.github.io/jujutsu-tutorial/
Bazaar, dat heb ik al lang niet meer gehoord...

Twintig jaar terug was er ineens een ontploffing in projecten die gedecentraliseerde versies controle systemen. Ik herinner me Monotone nog dat destijds gebruikt werd door OpenZaurus (nu Yocto), maar ik herinner me Bazaar toch vooral als derde paard in de race naast Mercurial en natuurlijk Git.

Vandaag kom je nauwelijks nog iets anders dan git tegen... In zekere zin een verarming, maar aan de andere kant werkt git gewoon goed voor de overgrote meerderheid van de projecten, en is het fijn dat je niet om het project met nieuwe tools voor hetzelfde probleem op te lossen moet leren werken.
Vandaag kom je nauwelijks nog iets anders dan git tegen... In zekere zin een verarming, maar aan de andere kant werkt git gewoon goed
Dat kun je wellicht ook zeggen over Linux. Een paar decennia geleden had je voor servers nog diverse Unix smaken, (HP-UX, Solaris, BSD*, IBM AIX, UnixWare, etc.) Je had ook nog OS/2 en NetWare. Tegenwoordig heb je alleen nog Linux (en er bestaat een niche voor Windows). Maar het is open source en werkt gewoon goed.

Daarbij denk ik dt je nog wel wat enthousiastelingen kunt vinden die iets positiefs willen zeggen over Solaris of OS/2. Probeer maar eens iemand te vinden die positief is over Microsoft Source Safe or Teams Version Control.

* Ik weet dat BSD nog bestaat, maar ik denk niet dat het een veel grotere rol speelt in de server-wereld dan bijvoorbeeld Windows. Voor embedded systemen misschien? Daar zal je ook diverse Realtime Operating Systems vinden die ik hier niet zal noemen.

[Reactie gewijzigd door 84hannes op 6 juni 2025 11:27]

Dat kun je wellicht ook zeggen over Linux. Een paar decennia geleden had je voor servers nog diverse Unix smaken, Solaris, BSD etc. Je had ook nog OS/2 en NetWare. Tegenwoordig heb je alleen nog Linux (en er bestaat een niche voor Windows). Maar het is open source en werkt gewoon goed.
*BSD bestaat nog steeds en wordt gebruikt in veel producten. Zie bijvoorbeeld OPNsense van Nederlandse bodem. Daarnaast bestaan er nog verschillende varianten van *nix in de enterprise wereld.

[Reactie gewijzigd door The Zep Man op 6 juni 2025 08:06]

ik weet niet meer welke distro dat was, maar was er niet een bekende BSD firewall distro juist aan het migreren naar linux (een beetje in het kielzog van truenas zeg maar)

https://www.netgate.com/b...ation-to-the-linux-kernel
SourceSafe |:( |:( Wat een bagger was dat. Elk ander systeem is beter.
Sourcesafe was slecht maar tfs kon best redelijk werken vooral ook in combinatie met policies werkte het redelijk.

Heb bazaar nooit gebruikt .

Maar inmiddels net als vrijwel iedereen al jaren op git naar volle tevredenheid (ondanks de gekke dingen die daar ook in zitten)
Een niche voor Windows? Ik denk dat je onderschat hoeveel er in deze wereld nog met Windows gewerkt wordt. Vele bedrijven zijn intern helemaal Microsoft gebasseerd. Gebruikers hebben een Windows laptop/desktop, er wordt Active Directory en Exchange gebruikt, filesharing gebeurt ook vanop Windows enzoverder. En als ik een cent zou moeten geven aan elk bedrijf dat bijv. hun DHCP servers op Windows draait, dan zat ik diep in de schulden.

Het komt wel veel minder voor wanneer je public facing webservices hebt, al zou ik het aantal websites dat er op draait nu ook weer niet onderschatten. Niet vergeten dat ze vaak ook weggestoken zitten achter loadbalancers en firewalls waardoor het verkrijgen van statistieken altijd onnauwkeurig zal zijn.
Gebruikers hebben een Windows laptop/desktop
Ik heb het in mijn verhaal expliciet over servers. Dat Windows op de Desktop gebruikt wordt weet ik, heb ik zelf op mijn werk ook (wel met virtuele Linux-machines voor productiviteit). En dat is precies waar de niche van Windows server zit: Active Directory, ofwel, om een domein met Windows (en Linux) desktop clients te beheren. Ik vermoed dat de DNS servers waar jij het over hebt ook met AD verbonden zijn, als het niet zelfs dezelfde servers zijn.

Hoe dan ook, niet de kern van mijn verhaal, maar leuk dat je zo fel reageert 😉
Blokker heeft het ook over servers.
Die 6 woorden die je hebt gequote zijn de enige in heel de tekst dat over gebruikers gaan.
Ik beheer een aantal bedrijfsapplicaties, die zonder uitzondering draaien op windows servers. IIS voor de webservices en MS SQL server voor de databases. Er is erg weinig niche aan de applicaties die ik beheer, ze zijn zonder uitzondering 'best-in-class'.

[Reactie gewijzigd door hottestbrain op 6 juni 2025 09:43]

Beweer je nu echt dat er nauwelijks Windows servers in gebruik zijn? Of snap ik je verhaal niet goed?
ongeveer is dat wel wat hij bedoelt,

of om het anders te zeggen, je hebt 3 servers nodig om een behoorlijk AD netwerkje te draaien en 5 exchange servers. maar dan heb je het ook wel gehad...

eigenlijk elk zichzelf respecterend bedrijf draait webservers EN database servers al niet meer op windows omdat MSSQL het echt aflegt tegen oracle of Posgres of allerlei andere data-structuren waar relational wat minder van toepassing is. en zodra je dingen doorzoekbaar wilt dan kom je al helemaal niet meer weg met MS producten, Lunce en elasticsearch zijn onovertroffen.

vervolgens zou ik ook 100x liever een storage cluster opzetten met truenas dan met windows storage server role.

in dat opzicht valt het me ook elke keer weer zo tegen dat er nog steeds geen goede antwoorden zijn voor de verschillende windows monopoliën.

als ik bijvoorbeeld kijk naar pydio en hoe zij van pydio8 (php) naar pydio cels (go) zijn gegaan en hoe die rewrite de performance heeft verbeterd dan zou ik willen dat men bij nextcloud iets soortgelijks zou doen vervolgens zou het echt heel nice zijn als men bij nextcloud de userbackend defacto zouden vervangen door lightldap en niet enkel als een potentiele update / hack / whatever. dan zou je ineens ook heel makkelijk SSO kunnen toevoegen en zouden bedrijven hun hele AD kunnen laten varen en vervangen door een combi van ldap sso en (M)DM er is hoe dan ook al nood aan een devicemanagement systeem dat meer doet dan alleen android of ios maar in plaats daarvan gewoon alles doet (dus ook windows).
Vreemd, ik werk in een snelgroeiend bedrijf met een omzet van honderden miljoenen en heb hier enkele duizenden servers die op Windows draaien, wat een veelvoud is van het aantal Linux servers. En wij zijn bijv. de afgelopen jaren net aan het overstappen van Oracle naar MSSQL.

Ik ken ook vele applicaties die we extern aankopen die ook exclusief op Windows draaien en ook vaak exclusief op MSSQL.

En jij spreekt van TrueNAS, leuk, maar dan heb je het ook al weer niet meer over enterprise grade materiaal. Kijk eens naar bijv. een Dell EMC, HP Nimble of tegenwoordig Hyper Converged met Cisco, Nutanix, VMware, ...

Linux heeft zeker zijn use cases, en er zijn ook grote multinationals die hoofdzakelijk of zelfs exclusief op Linux draaien, dat ga ik niet ontkennen. Maar in vele, grote bedrijven die al heel wat jaren meedraaien, blijft Windows ook op de serverkant groot.

En ja, we bekijken het alle twee vanuit onze eigen leefwereld, maar besef dat de echte wereld veel groter is dan wat we zelf dagelijks tegenkomen en dagelijks zien.
Windows Server heeft minder dan 10 (en volgens sommige statistieken minder dan 15) procent marktaandeel. Genoeg mensen hier op Tweakers die vinden dat macOS en Linux een niche zijn, met een gelijkaardig marktaandeel (onder de 10 of 15 procent, afhankelijk van welke statistiek je er voor macOS op nahoudt). Dus ja, op basis van díe logica is Windows Server ook een niche.
Maar dat kan je dus niet zomaar zeggen. Met die statistieken verwijst men vaak naar endpoint die op internet beschikbaar zijn. En terwijl heel veel laptops en desktops browsen op het net, zijn de meeste servers niet bereikbaar vanaf het internet. Hoe ga je dan ooit een goede statistiek opbouwen?

Ik durf zelf geen enkele uitspraak doen over hoe de verhouding zou liggen tussen de twee, simpelweg omdat het bijna onmogelijk is om na te gaan.
Welke bron heb jij voor “de meeste servers zijn niet bereikbaar via het internet”? Ik bedoel: ik weet dat er servers zijn die alleen lokaal bereikbaar zijn, maar of dat de meeste zijn, durf ik te betwijfelen.
Elk zichzelf respecterend bedrijf zorgt er voor dat servers niet zomaar op het internet kunnen, laat staan bereikbaar/scannable zijn vanaf het internet.
Deze zoomer heeft eerlijk gezegd nooit van bazaar gehoord
Ik moest aan Bazarr denken :+
Ik ook, maar durfde niet te commenten 🙈
Wel handige tool verder...
Git is prima, maar ik ben sinds een paar maanden overgestapt op een andere frontend. jj (jujutsu, https://github.com/jj-vcs/jj) is een alternatief voor git. Het gebruikt git als storage en interop layer, maar is veel eenvoudiger in gebruik. Echt een aanrader!

Op dit item kan niet meer gereageerd worden.