Ga naar hoofdinhoud

🧪 Handleiding voor de ontwikkelbranch

Wilt u de nieuwste functies proberen voordat ze officieel worden uitgebracht? De branch dev bevat de allernieuwste verbeteringen en experimentele functies die uiteindelijk in de hoofdrelease terechtkomen.

Experimentele software

De branch dev is experimenteel en kan fouten, onvolledige functies of incompatibele wijzigingen bevatten. Gebruik hem alleen als u mogelijke instabiliteit accepteert en Libre WebUI wilt helpen verbeteren.

🎯 Wat is de dev-branch?​

De ontwikkelbranch (dev) is de plek waar nieuwe functies worden getest voordat ze in de stabiele branch main worden samengevoegd. Hij bevat:

  • Nieuwste functies die nog niet in stabiele releases zitten
  • Foutoplossingen die worden getest
  • Experimentele verbeteringen aan de interface en functionaliteit
  • Prestatie-optimalisaties die nog worden ontwikkeld

🚀 De dev-branch gebruiken​

Docker-configuratie (aanbevolen)​

De Compose-bestanden voor ontwikkeling koppelen de Docker-socket van de host, zodat Work standaard functioneert wanneer Docker beschikbaar is. Taakcontainers draaien op de hostdaemon en verschijnen in docker ps. Stel op Linux eerst DOCKER_GID in .env in.

Met externe Ollama:

# Clone the repository
git clone https://github.com/libre-webui/libre-webui.git
cd libre-webui

# Switch to dev branch
git checkout dev

# Start the dev image with external Ollama
docker compose -f docker-compose.dev.external-ollama.yml up -d

Eenvoudige Docker:

# Use the dev branch image
docker run -d -p 3000:3001 -v libre-webui:/app/backend/data --name libre-webui-dev --restart always ghcr.io/libre-webui/libre-webui:dev

Vanuit de broncode​

# Clone and switch to dev branch
git clone https://github.com/libre-webui/libre-webui.git
cd libre-webui
git checkout dev

# Install dependencies
npm install

# Start development server
npm run dev

Vite kan klaar zijn voordat de backend zijn opstartcontroles heeft afgerond. Bij een lokale backend wacht de ontwikkelproxy tot 10 seconden op de listener voordat hij een API-aanvraag doorstuurt. Elke aanvraag wordt één keer doorgestuurd, ook schrijfacties; mislukte aanvragen worden niet opnieuw afgespeeld. Blijft de backend onbereikbaar, dan geeft de proxy HTTP 503 met een hint om het opnieuw te proberen. Statische frontendbestanden blijven tijdens het wachten beschikbaar.

Chat blijft opnieuw verbinden na tijdelijke backenduitval, met wachttijden tot maximaal 30 seconden. Een geslaagde verbinding zet de wachttijd terug; afmelden annuleert openstaande pogingen. Authenticatiefouten stoppen het automatisch opnieuw verbinden.

Work testen​

  1. Start Docker en controleer dat docker info slaagt als dezelfde gebruiker die de backend uitvoert.
  2. Start Libre WebUI vanuit de broncode met npm run dev.
  3. Meld u aan als beheerder.
  4. Selecteer Work en gebruik een Ollama- of Ollama Cloud-model met toolondersteuning, of een geconfigureerd model via een plug-in.

Voer de gerichte tests voor backendproviders en containerbeleid uit met:

npm run test:work

De tests controleren het gegenereerde Docker-beleid, padinsluiting, levenscyclus- en capaciteitsgedrag en de OpenAI-compatibele, Anthropic- en Gemini-tooladapters. Zie Work: geïsoleerde werkruimten voor de volledige runtimegrens.

🔄 Actueel blijven​

De dev-branch wordt vaak bijgewerkt. Zo haalt u de nieuwste wijzigingen op:

# Update your local dev branch
git pull origin dev

# Refresh the dev Compose stack
docker compose -f docker-compose.dev.external-ollama.yml pull
docker compose -f docker-compose.dev.external-ollama.yml up -d

# Or restart simple Docker
docker pull ghcr.io/libre-webui/libre-webui:dev
docker stop libre-webui-dev && docker rm libre-webui-dev
docker run -d -p 3000:3001 -v libre-webui:/app/backend/data --name libre-webui-dev --restart always ghcr.io/libre-webui/libre-webui:dev

🐛 Een fout gevonden? Help ons verbeteren!​

Uw foutmeldingen zijn bijzonder waardevol. Zo meldt u problemen doeltreffend:

Vóór u een melding maakt​

  1. Controleer bestaande issues: doorzoek GitHub Issues om duplicaten te voorkomen
  2. Probeer de stabiele versie: bevestig dat de fout alleen in dev bestaat (niet in de main-branch)
  3. Reproduceer consequent: kunt u de fout opnieuw laten optreden?

Fouten melden​

🐛 Meld een fout op GitHub

Neem deze informatie op:

**Environment:**

- Branch: dev
- Version: [git commit hash or date]
- OS: [Windows/macOS/Linux]
- Browser: [Chrome/Firefox/Safari version]
- Setup: [Docker/Source/etc.]
- Docker: [version and whether `docker info` succeeds, for Work issues]
- Work model/provider: [exact route, when applicable]

**Bug Description:**
Clear description of what went wrong

**Steps to Reproduce:**

1. Go to...
2. Click on...
3. See error...

**Expected Behavior:**
What should have happened

**Actual Behavior:**
What actually happened

**Screenshots/Logs:**
[If applicable, add screenshots or error logs]

**Work Activity:**
[Relevant tool call/result or preview output, with secrets removed]

Uw Git-commit-hash opvragen​

# Find your current dev branch commit
git rev-parse HEAD

# Or get a short version
git rev-parse --short HEAD

🏆 Bijdragen en erkenning​

Als u de dev-branch gebruikt, maakt u deel uit van onze testgemeenschap. Bijdragers krijgen op verschillende manieren erkenning:

Erkenning voor bijdragers​

  • Vermelding in CONTRIBUTORS.md
  • Vermelding in releaseopmerkingen voor belangrijke bijdragen
  • Toekenning als coauteur in commitberichten
  • Speciale dank in projectaankondigingen

Huidige bijdragers​

Onze geweldige gemeenschap bestaat onder meer uit:

  • rob - Projectbeheerder
  • jm - Verbetering van netwerktoegang
  • En meer bijdragers! Bekijk de volledige lijst

Wilt u code bijdragen?​

  1. Fork de repository
  2. Maak een featurebranch vanaf dev: git checkout -b feature/amazing-feature dev
  3. Breng uw wijzigingen aan
  4. Dien een Pull Request in voor de branch dev

Bekijk onze richtlijnen voor bijdragen voor gedetailleerde instructies en ons Community Charter voor de ethische richtlijnen en het governancemodel van het project.

Pull Request-controles​

Elke pull request, ook een gestapelde pull request naar een tussenliggende feature- of fixbranch, voert de workflow Format & Lint uit. De onafhankelijke taken controleren opmaak, linting van frontend en backend, TypeScript-typen, pakket- en regressietests en de Playwright-browsersuite. Chromium voert de volledige browsersuite uit. WebKit en Firefox voeren daarnaast de kritieke flows voor authenticatie, streaming, dialoogvensters, tabbladen, automatiseringen, opslag, Work en spraakweergave uit. Elke engine draait in een eigen CI-taak, en mislukte uitvoeringen uploaden afzonderlijke testresultaten.

De geteste npm-tarball wordt op Linux, macOS en Windows geïnstalleerd in een nieuwe consumentenmap, met zowel Node 22.22 als Node 24. Deze controles installeren echte productieafhankelijkheden zonder de node_modules van de checkout te lenen, en verifiëren daarna het opstarten van de CLI, de gereedheid, het serveren van de frontend en de gegevens na een herstart. Voer dezelfde controle lokaal uit na npm run build met npm run test:package-install; geef een tarball of een map met één tarball mee om een specifiek artefact te testen. Een schone installatie heeft toegang tot het register nodig, plus de normale buildvereisten van het platform voor native modules wanneer een vooraf gebouwde afhankelijkheid niet beschikbaar is.

Een aparte Work Computer-taak bouwt de GUI-image vanaf de vastgepinde basis van de runtime en voert de echte interactieregressietest uit. Met TEST_WORK_COMPUTER=1 laat een ontbrekende Docker-daemon of image de controle mislukken in plaats van haar over te slaan. Om dit lokaal te reproduceren, stelt u die vlag en WORK_COMPUTER_TEST_IMAGE in op een apart gebouwde testimage en voert u daarna npm run test:work-computer uit. Zonder de verplichte modus melden lokale uitvoeringen nog steeds dat de test is overgeslagen als de optionele GUI-fixture ontbreekt.

Deze matrix voegt controles toe voor de ondersteunde onderdelen; ze maakt geen niet-ondersteunde combinaties mogelijk. Node-lokale CLI-referenties blijven onbeschikbaar voor externe teamworkers.

CodeQL controleert JavaScript/TypeScript-, Python- en workflowcode bij elke pull request. De uitvoerbare Python-providerservers onder examples/ zijn in .gitattributes expliciet als code geclassificeerd, zodat de taaldetectie van GitHub ze meeneemt. De aparte beheerde Code Quality-configuratie moet zowel JavaScript/TypeScript als Python bevatten. Als er na een fix historische bevindingen overblijven, controleer dan de geanalyseerde revisie en de taaldekking en vernieuw de betreffende analyse nadat de wijziging is gepubliceerd. Wijs geldige bevindingen niet af en verander geen correct asynchroon gedrag alleen om een getoonde score te verbeteren.

De workflow Electron Dev Build verpakt ook artefacten voor macOS, Windows en Linux. macOS-builds voor pull requests behouden de ad-hocondertekening zonder referenties van het project, zodat de verpakte toepassing vóór het uploaden kan worden geverifieerd. De pull-requestworkflow ontvangt geen Developer ID- of notarisreferenties.

De workflow Docker Build Test and Push bouwt voor elke pull request zowel amd64- als arm64-images, inclusief gestapelde pull requests naar tussenliggende branches. Pull-requestbuilds melden zich niet aan bij een containerregister en pushen geen imagedigests of multi-architectuurmanifest.

Voer dezelfde controles op applicatieniveau lokaal uit voordat u een pull request opent:

npm run format:check
npm run lint
npm run test:package
npm run test:e2e

⚠️ Belangrijke opmerkingen​

Gegevensveiligheid​

  • Maak een back-up van uw gegevens voordat u naar de dev-branch overschakelt
  • Bestanden van Work-taken staan in afzonderlijke benoemde Docker-volumes libre-work-*. Maak daarvan los van de SQLite-gegevensmap een back-up voordat u destructieve wijzigingen aan de levenscyclus van taken of gebruikers test.
  • Gebruik een afzonderlijk Docker-volume voor dev-tests: 
    # Use different volume name for dev
    docker run -d -p 3000:3001 -v libre-webui-dev:/app/backend/data --name libre-webui-dev ghcr.io/libre-webui/libre-webui:dev

Mogelijke problemen​

  • Incompatibele wijzigingen kunnen configuratie-updates vereisen
  • Functies kunnen onvolledig zijn of zonder voorafgaande waarschuwing veranderen
  • Prestaties kunnen variëren terwijl optimalisaties worden getest
  • Interface-elementen kunnen er anders uitzien of zich onverwacht gedragen

Wanneer u stabiel moet gebruiken​

Ga terug naar de stabiele branch main als u:

  • Betrouwbaarheid voor belangrijk werk nodig hebt
  • Te veel fouten ondervindt
  • Een geteste, stabiele ervaring wilt
# Switch back to stable
git checkout main
docker compose -f docker-compose.external-ollama.yml pull
docker compose -f docker-compose.external-ollama.yml up -d

🌟 Word lid van de gemeenschap​

Klaar om de toekomst van Libre WebUI mede vorm te geven? 🚀

Uw tests, feedback en bijdragen op de dev-branch verbeteren rechtstreeks de ervaring voor alle gebruikers. Bedankt dat u deel uitmaakt van onze ontwikkelgemeenschap!