Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Als systeem en componenteigenaar wil ik versiebeheer over CG componenten, modellen en documentatie kunnen inregelen en middels datamanagement technieken bronverwijzingen kunnen actualiseren #81

Open
5 of 9 tasks
matthiasoliveiro opened this issue Jun 23, 2022 · 2 comments
Assignees
Labels
backend-development This issue requires development on the backend frontend-development Frontend development needed
Milestone

Comments

@matthiasoliveiro
Copy link

matthiasoliveiro commented Jun 23, 2022

"Als systeem en componenteigenaar wil ik versiebeheer over CG componenten, modellen en documentatie kunnen inregelen en middels datamanagement technieken bronverwijzingen kunnen actualiseren, zodat ik een goede scheiding kan doorvoeren tussen productie versies en doorontwikkelingen.

De lifecycle van objecten kan worden bijgehouden in OpenCatalogi

OpenCatalogi ondersteunt datamanagement

Lifecyclemanagement:

  • Zowel voor componenten in ontwikkeling als componenten die al gereleased zijn voor gebruik
  • Zowel portfolio lifecycle als developers status lifecycle
  • Kan verschillen per laag.
  • Zie attributen per laag
  • Versie gebruik
  • Willen weten welke versie wanneer gebruikt is
  • Welke notificaties triggers?
  • Rappelleren voor end-of-life, end-of-support en in productie (te abonneren

User stories:

 Acceptatiecriteria:

  • Als gebruiker wil ik bij een component de huidige en vorige versies zien op de component detail pagina
  • Als gebruiker wil ik bij een installatie opgeven welke versie dit betreft
@rubenvdlinde rubenvdlinde added Epic refinement-needed This issue needs to be refined labels Jun 24, 2022
@rubenvdlinde
Copy link
Contributor

rubenvdlinde commented Jun 28, 2022

Dit valt uit elkaar in twee aspecten.

  1. Het component zelf heeft een versie
  2. De installatie bij de gemeente heeft een versie, als er meerder installaties zijn dan kunnen er ook meerdere versies zin

Aan de kant van het component kunnen we dit redelijk simpel bijhouden met https://semver.org/ installaties wordt iets moelijker. Dat zou suggereren dat we ook installatie objecten bij gaan houden. En hoe gaan we dan installatie bijhouden?

@RonaldvCortenberghe
Copy link
Contributor

Wat er volgens mij gewenst is dat er versies bij componenten worden weergegeven, daarvoor moet de PO van dat component dat wel bij houden.
Ook wil je bijvoorbeeld weten welke versie door welke organisatie gebruikt worden, daar moeten ze dan wel een OC-installatie hebben.
Wat je dan niet wil is dat als jij als organisatie hebt aangegeven versie 1.3 te gebruiken van een component en de PO van dat component een nieuwe versie oplevert (versie 1.4) jij als organisatie ook ineens versie 1.4 schijnt te gebruiken zonder dat je iets gedaan hebt (en dus nog steeds versie 1.3 gebruikt).
Wat je wel wilt is dat het duidelijk wordt dat er een nieuwe versie is en wat de end-of-life datum is van de versie die jij gebruikt (als de PO dat heeft gedocumenteerd)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backend-development This issue requires development on the backend frontend-development Frontend development needed
Projects
No open projects
Status: In progress
Development

No branches or pull requests

5 participants