De ervaring met de patch van 1 juli 2013 laat zien dat de huidige beheeruitgangspunten voor StUF onderlaag en sectormodellen niet ideaal zijn.
Het algemene uitgangspunt is immers dat gebruikers zelf verantwoordelijk zijn om bij gebruik van een Sectormodel steeds de meest actuele versie van de StUF onderlaag (en van bijvoorbeeld StUF bg) te gebruiken. De beheerder van het Sectormodel zorgt dan alleen voor een correctie versie van de "eigen schema's". Iedere gebruiker moet zelf de schema's die worden geïmporteerd actueel houden.
Deze werkwijze leidt ertoe dat bij een patch voor de StUF onderlaag die ertoe leidt dat Sectormodellen niet meer valideren, zoals de patch van afgelopen 1 juli 2013, de gebruikers geen "validerende versie" van een Secormodel hebben. Immers wanneer zij conform de beheeruitgangspunten de meest recente versie van StUF onderlaag importeren, valideren de schema's niet. Ze moeten dan wachten tot de beheerder van het Sectormodel ook een patch heeft uitgebracht om weer met validerende schema's te kunnen werken.
Daarom is het wellicht toch beter om de beheeruitgangspunten aan te passen en de beheerder van een Sectormodel te laten bepalen welke versie (welke patch) van de onderliggende schema's wordt gebruikt bij een bepaalde versie (patch) van het Sectormodel. Dat betekent dat bij overgang naar die werkwijze bij publicatie van het Sectormodel ook steeds de onderliggende schema's mee worden gepubliceerd. Dat betekent overigens ook dat er een nieuwe patch van een Sectormodel komt, wanneer het Sectormodel "meegaat" met een patch van de onderliggende schema's, terwijl aan de "eigen" schema's niets verandert.
Ik hoor graag wat andere (beheerders van Sectormodellen/gebruikers) van deze wijziging van de beheeruitgangspunten vinden, zodat het daarna in expertgroep en beheergroep besproken kan worden.
De voorgestelde oplossing (geef per sectormodel aan wat de laatste ondersteunde patch van de onderlaag is) maakt het er niet gemakkelijker op voor leveranciers van pakketten die meerdere sectormodellen (moeten) ondersteunen. Deze situatie is dan al bijna niet werkbaar meer door onnodige complexiteit. Ik denk dat het veel belangrijker is om het onderliggende probleem aan te pakken: het niet downwards compatible zijn van patches en dan met name van patches in de onderlaag. Er moet wel een heel dringende noodzaak zijn om dergelijke (niet downwards compatible) wijzigingen door te voeren in patches. Er moet een duidelijk probleem worden opgelost, voordat we dit toestaan. De kans is immers groot dat er meer problemen worden veroorzaakt dan opgelost.
Wat is "De ervaring met de patch van 1 juli 2013"? Als dat niet duidelijk wordt gemaakt hebben we het alleen over luchtkastelen. Er bestaat geen goede oplossing voor een onduidelijk probleem.
Dit Erratum is opgevoerd in de onderhoudsverzoeken als ERR292.
De lijst met onderhoudsverzoeken vind je op:
gemmaonline.nl/index.php/StUF-Expertgroep#Documenten
De bedoelde ervaring van de patch van 1 juli was dat de schema's van het sectormodel WOZ per 1 juli niet meer valideerden, door de patch op de onderlaag. Dus zonder dat er sprake was van een wijziging in StUF woz 03.12, waren wel ineens de schema's "onbruikbaar". Dat was de ervaring die ik bedoelde en in de toekomst wil vermijden.
Tijdens de StUF Expertgroep van 19 april 2017 heeft Robert voorgesteld dit erratum af te voeren. Hij geeft aan dat KING middels regressietesten op het STP al checkt of er problemen optreden met sectormodellen en koppelvlakken als er nieuwe patches en versies worden uitgebracht. Dit probleem wordt daarmee naar zijn mening al ondervangen.
Verder zal versiebeheer sowieso flink op de schop gaan met de nieuwe werkwijze.
Annemiek heeft echter het idee dat een goede beschrijving nog belangrijker wordt.
Volgens haar is het nog niet goed beschreven hoe we er voor kunnen zorgen dat het goed gaat.
De werkwijze moet dus wel beschreven worden. Het beheermodel moet volgens Maarten aangepast worden aan de nieuwe praktijk. Er moet duidelijk worden op welke patch je zit als je met scherpe koppelvlakken werkt.
De StUF Expertgroep besluit uiteindelijk het om te zetten naar een RFC (RFC0483), het moet in het nieuwe beheermodel worden aangepast.