Versioning mess
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 35/100
Direzione di ricerca
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.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
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
- Lingua principale
- Shell
- Stelle
- 5
- Fork
- 9
- Merge medio
- 16h 28m
- PR unite (30g)
- 5
Guida per i contributori
Nessuna guida per i contributori indicizzata per questo repository
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di eclipse-score/devcontainer
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 52/100
eclipse-score/devcontainer#115 · 6 commenti ·
-
Dependency Dashboard Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 20/100
eclipse-score/devcontainer#114 ·
Tutte le issue di eclipse-score/devcontainer
Issue simili
-
Bob Shell support Apertaenhancement
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
-
tooling
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
openSUSE/python-rpm-macros#219 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
YunoHost-Apps/adguardhome_ynh#258 ·
-
steam-short-session-tracker: incorrect registry backup path resets settings during automatic repair Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 80/100
ValveSoftware/SteamOS#2829 ·