Als beheerder wil ik weten hoeveel versies van een standaard beheerd moeten worden zodat ik weet wanneer een versie de status 'eind gebruik' moet krijgen. about api-beheer HOT 6 OPEN

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.