Change- en releasebeleid

Het afsprakenstelsel is een samenhangend geheel, bestaande uit een aantal bouwblokken. Typerend is dat een wijziging vaak raakvlakken heeft met meerdere bouwblokken. Daarom worden nieuwe versies van de gehele afsprakenset uitgebracht en niet van losse delen afzonderlijk. Een release kan zowel changes als uitbreidingen op het stelsel bevatten. Er wordt gewerkt met twee actieve releases: een actuele en een versie die wordt uitgefaseerd. De versies zijn opeenvolgend en voortbouwend op de vorige versie. Dit voorkomt dat er parallelle versies worden uitgegeven met afwijkende en/of tegenstrijdige inhoud.

 Verantwoordelijkheden

• Zorgeloos Vastgoed: verantwoordelijk voor het afstemmen, doorvoeren en uitrollen van changes en toevoegingen op het afsprakenstelsel. Daarbij streeft zij naar een minimale impact voor aangesloten partijen.

• Participanten: hebben de verantwoordelijkheid om zowel te adviseren over ingediende changes en toevoegingen (RFC's) en deze ook zelf aan te dragen.

• Softwareleveranciers (Dienstverleners & Consumenten): kunnen gewenste changes en aanvullingen (RFC’s) indienen en zijn verantwoordelijk voor het tijdig implementeren van de geldende versie van het stelsel.

Procesbeschrijving totstandkoming release

De samenstelling van iedere release wordt vastgesteld door het bestuur op basis van het jaarplan. De releases volgen de vastgestelde cyclus. Enkel het bestuur kan besluiten daarvan af te wijken. 

Participanten en Aangeslotenen (Softwareleveranciers) kunnen meedenken en -werken aan wijzigingen en toevoegingen op het afsprakenstelsel. Verzoeken daartoe (RFC’s) dienen te worden voorzien van een toelichting en/of motivatie. Zorgeloos Vastgoed verzorgt een eerste screening van de RFC’s en beoordeelt daarbij of het om een Change of Toevoeging gaat en wat de urgentie hiervan is. Daarbij wordt onder andere gekeken naar het type (Change of Toevoeging), de urgentie, de omvang en de aansluiting bij het jaarplan. Indien nodig wordt een verdere analyse of uitwerking van de RFC in gang gezet door ze te behandelen in werk- en/of expertgroepen.

Tijdens het verwerken van de RFC’s is de releaseplanning leidend. Eventueel wordt rekening gehouden met een implementatieplanning, waarbij een kortere of langere termijn voor de implementatie geldt. Zorgeloos Vastgoed stemt af met alle betrokkenen en verzorgt een openbare consultatie conform het Ontwikkelproces. Waar nodig wordt tijdig geëscaleerd, bijvoorbeeld wanneer er problemen optreden bij het tijdig implementeren van het afsprakenstelsel.

Releasecyclus

Na de eerste oplevering van het afsprakenstelsel wordt gewerkt met een halfjaarlijkse release. De vaste releasemomenten zijn nader te bepalen. Releases bestaan zoveel mogelijk uit een samenhangende set van wijzigingen en toevoegingen (‘releasethema’), maar bevatten mogelijk ook noodzakelijke wijzigingen voortkomend uit veranderende wetgeving of technologie.

Om te zorgen voor de benodigde flexibiliteit zijn er op ieder twee releases geldig. De nieuwste versie krijgt het etiket ‘Actief’ mee, waarop de voorgaande versie het etiket ‘Verouderd’ krijgt. Softwareleveranciers dienen altijd tenminste één van deze versies (Verouderd of Actief) te ondersteunen.

Zodra een nieuwe versie van het afsprakenstelsel wordt gereleased, gebeurt het volgende:

• De versie met status Verouderd degradeert naar Teruggetrokken.

• De versie met status Actief degradeert naar Verouderd, waardoor dit de minimale afsprakenset is waaraan men dient te voldoen.

• De nieuwe versie ontvangt de status Actief.

Versionering

Iedere versie van het afsprakenstelsel kent een uniek versienummer. Hierbij worden twee cijfers gebruikt (bijvoorbeeld v1.2). Releases die volgens de jaarlijkse cyclus uitkomen, dan wel tussentijds zonder zogenaamde "backwards compatibility" en/of met significante wijzigingen, worden getypeerd als een major release. Hierbij wordt het versienummer vóór de punt met één verhoogd (bijvoorbeeld van v1.2 naar v2.0). Tussentijdse, minor releases worden gekenmerkt door een ophoging van het versienummer achter de punt met één (bijvoorbeeld van v1.2 naar v1.3). Voor bugfixes wordt een extra toevoeging achter de tweede punt gebruikt (bijvoorbeeld v1.2.2).

Buiten de versionering kunnen nog wijzigingen aangebracht worden in de documentatie die geen impact hebben op de werking van het stelsel. Het kan daarbij bijvoorbeeld gaan om grammaticale fouten of ontbrekende links. De aanpassingen daarvan worden direct doorgevoerd in de Actieve versie en bijgehouden op de changelog.