Discussion: how to handle SPDX Spec version 3 dot releases

Abierto
#390 11 comentarios 1 reacción 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
30/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Tranquilo
Stack tecnológico
java
Área
backend

Línea de trabajo

Comienza revisando el generador de código spdx-model-to-java y cómo gestiona actualmente esta biblioteca las versiones de la especificación SPDX 2. Compara los cuatro enfoques propuestos para paquetes e interfaces, incluida la compatibilidad de los enum y la validación de versiones anteriores; se considerará terminado cuando los maintainers hayan decidido cómo deben representarse las versiones menores de SPDX 3.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

enhancement

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:

  1. Just produce the latest version and drop support for earlier dot releases
  2. Produce one package per dot release
  3. Produce one package per dot release plus a "latest" package (e.g. org.spdx.library.model.v3_latest)
  4. 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.

Lenguaje dominante
Java
Estrellas
71
Forks
44
Merge medio
12 h 54 min
PR fusionados (30 d)
7

Guía de contribución

Abrir la guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de spdx/Spdx-Java-Library

Todos los issues de spdx/Spdx-Java-Library

Issues similares

Más issues de Java

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.