Comments (6)
We hebben het steeds over "het nieuwe naast het oude", niet voor niets, omdat de problemen die hierboven beschreven eigenlijk alleen spelen in de oude softwarewereld. Waar je op moet mikken is software waarbij overgaan van 17 naar 18 geen "migratie" is maar domweg een druk op de knop. Software waarbij het geen uitdaging is om iedereen op dezelfde versie te krijgen binnen korte termijn.
Dat is natuurlijk ideaal en ik hoop dat het in de praktijk ook zo gaat werken. Voor het geval dat dit niet zo is geldt het bovenstaande voorstel.
from api-beheer.
Voorzetje in https://github.com/maykinmedia/demo-api
Zie ook #48
Het aantal actieve versies hangt dus af hoe snel de opvolgende versies uit komen. Ik vind zelf dat je de major versies een vaste tijd moet ondersteunen (zeg een jaar), maar als je dan in 1 maand tijd versie 1, 2 en 3 uit brengt, dan moet je deze dus alle drie een jaar lang ondersteunen.
from api-beheer.
@joeribekker, @michielverhoef: Vanochtend met Michiel een discussie gehad over hoe je het uitfaseren van een versie van een standaard zou kunnen inregelen. In de API strategie staat er op dit moment dat er maximaal 3 versies van een API ondersteund hoeven te worden. Een goed uitgangspunt denk ik. De vraag is echter hoe we er voor gaan zorgen dat we versie 18 kunt uitbrengen terwijl diverse implementaties van de Provider versie 15 nog als hoogste versie voeren. Iets wat nodig is ter voorkoming dat Consumers meer dan 3 versies van een standaard moeten ondersteunen.
Ik denk dat we moeten aangeven dat we pas een nieuwe versie publiceren (de status 'in gebruik' geven) als er alle Providers een versie ondersteunen die hooguit 2 lager is dan de uit te brengen versie (in dit voorbeeld dus 16). Ter voorkoming dat we in een situatie terecht komen zoals met StUF 2.04 (deze wordt jarennadat versie 3.10 in gebruik is genomen nog steeds op heel veel plaatsen gebruikt) en we dus aan het publiceren van versie 18 niet toekomen zullen gemeenten bij leveranciers meer moeten sturen op het tijdig upgraden van de Provider applicaties. Dat vereist echter dat ook gemeenten het belang inzien van het tijdig upgraden naar een nieuwe versie. Niet alle gemeenten zullen immers behoefte hebben om met nieuwe versies gepaard gaande functionaliteit te implementeren. Dat hoeft ook niet een gemeente kan nl. steeds 1 versie overslaan om bij te kunnen blijven maar daarna moeten ze toch echt over naar een nieuwe versie. Gemeenten zullen zich moeten commiten aan dit regime en elkaar er op aan moeten spreken als dit niet gebeurd. Dit is een spel dat zij onderling moeten spelen met als uiterste consequentie dat een nieuwe gewenste versie niet 'in gebruik' genomen wordt.
from api-beheer.
Niet alle gemeenten zullen immers behoefte hebben om met nieuwe versies gepaard gaande functionaliteit te implementeren. Dat hoeft ook niet een gemeente kan nl. steeds 1 versie overslaan om bij te kunnen blijven maar daarna moeten ze toch echt over naar een nieuwe versie.
Dus in dit voorbeeld zou een gemeente de overstap van versie 15 naar versie 17 kunnen maken waarna de weg vrij is om versie 18 in gebruik te nemen?
Nadeel is wel dat zo'n gemeente waarschijnlijk niet gelijk weer over zal gaan naar versie 18 (ze hebben net een migratie achter de rug) maar daar moeten we dan maar eens naar kijken. Is ook een kwestie van goed uitleggen dat elke keer een klein stapje doen veel makkelijker gaat dan om de paar versies een hele grote stap doen. Plus dat je als gemeente goed mee gaat met de ontwikkelingen.
from api-beheer.
We hebben het steeds over "het nieuwe naast het oude", niet voor niets, omdat de problemen die hierboven beschreven eigenlijk alleen spelen in de oude softwarewereld. Waar je op moet mikken is software waarbij overgaan van 17 naar 18 geen "migratie" is maar domweg een druk op de knop. Software waarbij het geen uitdaging is om iedereen op dezelfde versie te krijgen binnen korte termijn.
from api-beheer.
Zie #85 voor een voorstel m.b.t. versiebeheer.
Dat voorstel moet ook met het licht op #82 bekeken worden.
from api-beheer.
Related Issues (20)
- Als informatiemanager wil ik dat in de documentatie een overzicht is opgenomen van de resources met de bijbehorende attributen die in de API beschikbaar zijn
- Als informatiemanager wil ik dat in de documentatie een UML diagram opgenomen is van de resources en relaties die in de API beschikbaar zijn
- Als gebruiker wil ik weten hoe ik de referentie implementatie van een standaard kan installeren
- Als gebruiker wil ik weten wat de business logica van de standaard is
- Als gebruiker wil ik een overzicht van de wijzigingen met daarin per versie wat is toegevoegd/veranderd
- Als beheerder wil ik een procedure waarmee ik kan testen dat een OAS3 up-to-date is met de gerelateerde referentie-implementatie (die in dockerHub en de testomgeving staat);
- Als beheerder wil ik een of meer procedures hebben waarin beschreven staat hoe ik met docker containers om moet gaan op DockerHub/Haven (nieuwe inbrengen, verwijderen, etc...);
- Als beheerder wil ik procedures hebben voor API beheeractiviteiten op DockerHub/Haven die niet direct te maken hebben met docker containers
- Als beheerder wil ik weten tegen welke problemen ik aan kan lopen op DockerHub/Haven en hoe ik daar dan op moet handelen HOT 2
- Als leverancier/gemeente wil ik weten wat ik allemaal moet doen om de referentie-implementatie in DockerHub/Haven te kunnen gebruiken
- Als beheerder wil ik weten hoe ik de problemen bij het hosten van versies van referentie implementaties kan oplossen. HOT 2
- beheerder wil ik een methode waarmee ik kan monitoren of er problemen optreden met gehoste versies van een Referentie Implementatie HOT 6
- Demo sprint x (dd mmm yyyy)
- Wat gaan we doen met de backlog van ZGW nadat de ZGW APi's in beheer zijn genomen HOT 3
- Hoe richten we versiebeheer en releasemanagement in? HOT 1
- Gitlab of Github? HOT 1
- Als beheerder van een standaard wil ik dat de referentie implementaties up to date gehouden worden HOT 2
- Als beheerder wil ik een goed overzicht hebben van het beheerlandschap HOT 1
- Als gebruiker van een API standaard wil ik een SLA
- Als leverancier wil ik in de SoftwareCatalogus kunnen aangeven dat mijn applicatie voldoet aan de ZGW-standaard HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from api-beheer.