Discussion: how to handle SPDX Spec version 3 dot releases
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 30/100
Direzione di ricerca
Inizia esaminando il generatore di codice spdx-model-to-java e il modo in cui questa libreria gestisce attualmente le versioni della specifica SPDX 2. Confronta i quattro approcci proposti per package e interfacce, inclusi la compatibilità degli enum e la validazione delle versioni precedenti; il lavoro è considerato completato quando i maintainer hanno deciso come rappresentare le versioni dot di SPDX 3.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Adding support for the SPDX 3.1 release will require an update to spdx-model-to-java code generator to support multiple dot releases of the spec.
The simplest approach would be to just add another package specific to the dot release (e.g. org.spdx.library.model.v3_1).
This, however, will require all applications that access the model through Java update their imports to the new version - including the utilities in this library.
Since dot releases are backwards compatible, we could create a package which is always the "latest" - this is similar to how we treat the SPDX 2 spec versions.
I can think of a few specific alternatives:
- Just produce the latest version and drop support for earlier dot releases
- Produce one package per dot release
- Produce one package per dot release plus a "latest" package (e.g.
org.spdx.library.model.v3_latest) - Use interfaces rather than class hierarchies and use multiple interfaces and an interface hierarchy to create a common interface that would work across all versions
In looking into 4, I ran into problems with the enums since you can not extend the enum classes and there is no straightforward way that I could find to support a compatible enum class that allows extensions for later dot releases (e.g. adding additional relationship types). 4 is also the most complex and involved solution.
Implementing 3 would be straightforward and I believe will support most use cases.
2 has the issue of requiring code updates on every release to change the imports.
1 doesn't support validating previous versions.
- Lingua principale
- Java
- Stelle
- 71
- Fork
- 44
- Merge medio
- 12h 54m
- PR unite (30g)
- 7
Guida per i contributori
Apri la guida per i contributori
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 spdx/Spdx-Java-Library
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 30/100
spdx/Spdx-Java-Library#449 ·
-
question
Difficoltà 5/5 Più di una settimana Idoneità per principianti 30/100
spdx/Spdx-Java-Library#398 ·
-
wontfix
Difficoltà 3/5 1-2 giorni Idoneità per principianti 45/100
spdx/Spdx-Java-Library#393 · 2 commenti · 1 reazione ·
-
matching
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
spdx/Spdx-Java-Library#392 · 4 commenti ·
-
matching performance
Difficoltà 4/5 3-5 giorni Idoneità per principianti 35/100
spdx/Spdx-Java-Library#369 · 3 commenti · 2 reazioni ·
Tutte le issue di spdx/Spdx-Java-Library
Issue simili
-
documentation
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
inu-appcenter/memorIN-backend#288 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
-
frontend maui-pilot pilot-ask question
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
-
executions.Query — startDate and timeRange filters are sent with inverted comparison operators Apertaarea/plugin
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
kestra-io/plugin-kestra#190 ·