Versioning mess
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 35/100
Research direction
Start by comparing the per-feature version.yml files with the lockfiles under tools/lockfiles and the version references shown in pull request 153. Determine which sources should own apt, Python, and tool versions, then define a consistent replacement and update the affected files. Done means the duplicated version definitions and unnecessary manual maintenance are reduced.
Written by the indexing model from the issue text.
Description
Product Increment Description
Originally the devcontainer had a version.yml per devcontainer feature and no version definition was duplicated. This approach already carries the drawback, that we have to bump OpenJDK versions from time to time, when Ubuntu ships a new security update and removes the old packages.
Then came the run-tool script with its own lockfiles: https://github.com/eclipse-score/devcontainer/tree/main/tools/lockfiles
This is now partly another place defining versions. You can then see in pull requests like https://github.com/eclipse-score/devcontainer/pull/153 that versions are defined / set multiple times.
This creates a higher maintenance burden that we should have.
IMHO the hand written versions.yml just did not cause too much frustration because we never switched the Ubuntu version and the only package getting constant updates is OpenJDK. For packages installed via apt I would prefer that we create a lockfile automatically. The current approach ignores all transitive dependencies.
For the Python packages I would remove their version definition from versions.yml and just use what is in their lockfiles.
And we have to reconsider if tool versions need to be written down in a markdown file. Maybe referencing lockfiles is good enough.
Acceptance Criteria (DoD)
Version mess is improved
- Dominant language
- Shell
- Stars
- 5
- Forks
- 9
- Avg merge
- 16h 28m
- Merged PRs (30d)
- 5
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from eclipse-score/devcontainer
-
Difficulty 4/5 3-5 days Newbie friendliness 52/100
eclipse-score/devcontainer#115 · 6 comments ·
-
Dependency Dashboard Open
Difficulty 2/5 1-3 hours Newbie friendliness 20/100
eclipse-score/devcontainer#114 ·
All issues in eclipse-score/devcontainer
Similar issues
-
good-start
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
VilnaCRM-Org/user-service#497 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
conda-forge/spacy-feedstock#177 ·
-
area:jail bug security severity:low track:open-source
Difficulty 1/5 Under an hour Newbie friendliness 75/100