Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Library API: version each eligibility check individually

Aperta
  • Qualcosa non va?
#196 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Ferma
Stack tecnologico
java
Ambito
api, backend, release

Direzione di ricerca

Inizia con lo script tag-release e pom.xml, quindi esamina i modelli DMN e il git tag della versione precedente. Determina come i controlli di idoneità e i benefit modificati riceverebbero una proprietà di versione e come tale proprietà potrebbe essere esposta tramite library-api per gli utenti delle applicazioni web. Il lavoro è completato quando l'approccio al versioning è definito e le relative implicazioni per il release e l'API sono risolte.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Work is currently being done to version the library-api as a whole, but it would be nice to somehow tag individual eligibility checks (and benefits!) with a version so that web app users can be prompted to update if a check they are using is out of date OR auto-updated if there is no change to that specific check in the latest version of the library-api.

Idea: during the release of new versions of the library-api, we currently use the tag-release script to tag the repo and pom.xml with the new version. We could extend this script to diff all DMN models against their files at the previous version git tag, and if there have been changes, update a version property somewhere within the dmn model (and have that version property be accessibility somehow via the API so the web app can read it).

Pros:

  • No need to manage a separate versioning system for individual checks/benefits. (use the release script and you're good to go).

Cons:

  • The semantic versioning scheme would make sense at the whole API level, but not at the individual check/benefit level. For example, a minor version bump of the API might include breaking changes to one eligibility check, but not another. However, both checks would get the same version number (the new API version) even though only one changed. (perhaps this could be overcome by some sort of diff or AI summary of the change in the web app?).
Lingua principale
Java
Stelle
16
Fork
5
Merge medio
17h 24m
PR unite (30g)
23

Preparare l'ambiente

Non abbiamo ancora controllato i file di configurazione di questo progetto. Parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di CodeForPhilly/benefit-decision-toolkit

Tutte le issue di CodeForPhilly/benefit-decision-toolkit

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.