Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Library API: version each eligibility check individually

Open
  • Is something wrong?
#196 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Stale
Tech stack
java
Domain
api, backend, release

Research direction

Start with the tag-release script and pom.xml, then inspect the DMN models and the previous version git tag. Determine how changed eligibility checks and benefits would receive a version property and how that property could be exposed through the library-api for web app users. Done means the versioning approach is defined and its release and API implications are resolved.

Written by the indexing model from the issue text.

Description

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?).
Dominant language
Java
Stars
16
Forks
5
Avg merge
17h 24m
Merged PRs (30d)
23

Getting set up

We have not checked this project's setup files yet. Start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from CodeForPhilly/benefit-decision-toolkit

All issues in CodeForPhilly/benefit-decision-toolkit

Similar issues

More Java issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.