Annotations on their own version line: publish maddi-annotation and maddi-support only when they change

Abierto
  • ¿Algo no está bien?
#182 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
14/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
java, kotlin
Área
build-system, ci-cd, release

Línea de trabajo

Start with the version wiring in maddi-support/build.gradle.kts and maddi/gradle.properties, then the release-maddi gate in jfocus-devops. TestVersionSkew in maddi-dist is the check that must learn the new annotations version line. Done means maddi-annotation and maddi-support publish at 1.0.0 once, later releases skip them unless their sources changed, and the compatibility ratchet fails on removed or renamed annotations.

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

Descripción

maddi-annotation and maddi-support change far less often than the analyzer, the CLI zips and the build plugins. Today all of them share maddi's version (maddi-support/build.gradle.kts: "single release train"), so every maddi release republishes identical annotation jars to Maven Central, and asks every user to bump a dependency that did not change.

Why decoupling is safe

The analyzer recognises the annotations by fully qualified name, never by the jar's version: for example ShadowModificationPass (io.codelaser.maddi.annotation.Modified), NullabilityDecorator (...annotation.Nullable / NotNull) and SourceContractMaterializer (...annotation.rare.IgnoreModifications). Any analyzer can read code compiled against any annotations version, as long as one rule holds:

A maddi release understands every annotation in every published annotations version. Annotations and attributes may be added, never renamed or removed.

Proposal

  1. A version line of their own. Add annotationsVersion=1.0.0 to maddi/gradle.properties. Both modules publish under it instead of project.version, and maddi-support depends on maddi-annotation at annotationsVersion. One shared version, because they are always deployed together and support depends on annotation. Starting at 1.0.0 tells users the annotations are stable.

  2. Publish only when needed (jfocus-devops/gate/release-maddi, release maddi):

    • the version is already on repo1.maven.org: skip the two Central legs, and record "annotations 1.0.0, unchanged";
    • the annotation sources changed since that version's tag, but the version did not: refuse, so a change cannot go out unpublished;
    • otherwise publish as now: maddi-annotation first, let it reach repo1, then maddi-support.

    The v<maddi version> tag and the maddi-mod and maddi-dist steps are unchanged. Tag the annotations separately (annotations-v1.0.0).

  3. A compatibility ratchet. A committed list of every annotation type in maddi-annotation and maddi-support and its attributes. An addition passes, and updates the list; a removal or rename fails the gate.

  4. Follow-ups.

    • TestVersionSkew (maddi-dist), the gate over everything that names a maddi version, learns the new line.
    • The install instructions in the READMEs, the plugins' documentation and the release notes name the annotations version separately ("annotations: 1.0.0, unchanged").
    • docs/PUBLISHING.md and gate/RELEASE.md §A2.4 describe the two version lines.

Alternative considered

Keep the lockstep and republish identical jars each release. No work, but a dependency bump for users with every analyzer release, and Central versions that mean nothing.

Done when

  • 0.9.7 releases with maddi-annotation and maddi-support at 1.0.0 (one Central publish), and a later maddi release skips the annotation legs unless their sources changed.
  • The ratchet is in the gate.
Lenguaje dominante
Java
Estrellas
1
Forks
1
Merge medio
1 h 44 min
PR fusionados (30 d)
6

Preparar el entorno

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 CodeLaser/maddi

Todos los issues de CodeLaser/maddi

Issues similares

Más issues de Java

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.