Follow Hilla minor versioning

[mcollovati]

To be able to add tests introduced by Hilla minor versions, we should consider pinning the quarkus-hilla versioning to the Hilla minor versions.

This means that the current quarkus-hilla main should use Hilla 2.3-SNAPSHOT, and we should create 2.2 and 2.1 branches pinned to the relative Hilla latest version.
At every Hilla minor release, we should create a branch for the newly released version and bump main to the next Hilla snapshot.

The tasks to perform at every minor release (e.g A.B.0) should likely be

• Create quarkus-hilla A.B branch from main and pin Hilla version to A.B.0
• Update release.yaml to add branch A.B the selectable branch list
• Update dependabot configuration to add A.B target branch with the following ignore rules

    ignore:
      - dependency-name: "dev.hilla:*"
        update-types: [ "version-update:semver-major", "version-update:semver-minor"]
      - dependency-name: "com.vaadin:*"
        update-types: [ "version-update:semver-major", "version-update:semver-minor"]
  

• Update update-npm-deps.yaml to add A.B branch
• Update validation.yaml to add A.B branch on push trigger
• Update main to use Hilla A.<NEXT>-SNAPSHOT
• Release quarkus-hilla A.B.0 from branch A.B
• optional: create target/A.B label for cherry-picks. It could be done on demand.

Tasks:

• Create Branch 2.0
• Create Branch 2.1
• Create Branch 2.2
• Release quarkus-hilla 2.1.0
• Release quarkus-hilla 2.2.0
• Update main to 2.3-SNAPSHOT with Hilla 2.3-SNAPSHOT and Vaadin 24.2-SNAPSHOT (chore: prepare revision 2.3 #307)

After Hilla 2.3 stable release

• Create Branch 2.3 and update workflows
• Release quarkus-hilla 2.3.0
• Update main to 2.4-SNAPSHOT with Hilla 2.4-SNAPSHOT and Vaadin 24.3-SNAPSHOT

Additional tasks to be performed only once:

• Remove Vaadin BOM and property from root parent pom (Remove vaadin-bom dependency from parent pom #284) (chore: remove vaadin BOM from parent POM #302)
• Refactor validation-nightly.yaml to create the matrix based on branch names (main, 2.2, 2.1) instead of Hilla versions. Hilla version should be derived from branch name. (chore(actions): run snapshot validations on release branches #306

[Dudeplayz]

The patch version is then used for our versioning or should it also follow the hilla version and we add a fourth version number, e.g. 2.3.1.1 ?

[mcollovati]

Patch version will be specific for quarkus-hilla, since Hilla patches should not have features or breaking changes.

[Dudeplayz]

since Hilla patches should not have features or breaking changes.

I am not sure if this always applies to us, since we apply some bytecode hacks on code which could be seen as internal, thus changes can always happen. But I think we can go with the suggested versioning and if we encounter a version which has this problem, we add a .1 or something to only this one.

[mcollovati]

Good point! In such situations, we should probably try to find a backward-compatible way to apply our changes, so that for example, quarkus-hilla 2.2.N could work both with Hilla 2.2.X and 2.2.Y, where Y introduced a change that for us is breaking.

[Dudeplayz]

Sounds ok, but then we should track this somehow, because if a new minor version occurs, the compatibility code gets obsolete.

[Dudeplayz]

Another idea would be, to go with a double digit number as patch version, like kotlin. So that we always have the same as hilla and use our patch version als the last number, so 2.1.10, 2.1.20, ... is default and a patch is applied as 2.1.21, 2.1.22, ..., it looks better than 2.1.2.2

[mcollovati]

I don't like the double-digit idea that match, is seems a bit confusing to me.

we should track this somehow, because if a new minor version occurs, the compatibility code gets obsolete.

Maybe annotating code with the latest incompatible version (e.g. @CompatibilityFix("2.1.X")) and add something to the build so that it fails if the minor version does not match with the current project version.
For example, having that annotation somewhere in the code should work for 2.1-SNAPSHOT, but the build should fail with 2.2-SNAPSHOT

[Dudeplayz]

I don't like the double-digit idea that match, is seems a bit confusing to me.

Understandable.

Maybe annotating code with the latest incompatible version (e.g. @CompatibilityFix("2.1.X")) and add something to the build so that it fails if the minor version does not match with the current project version.
For example, having that annotation somewhere in the code should work for 2.1-SNAPSHOT, but the build should fail with 2.2-SNAPSHOT

Yea that sounds good, lets go with that. Maybe we can also use the quarkus build pipeline somehow, that it picks the code for the desired version. So that e.g. one function is for 2.1.2 and another for 2.1.3, annotated somehow. And the build / deploy stage then picks the desired function. We should examine which is the safest and easiest solution.

[mcollovati]

Maybe we can also use the quarkus build pipeline somehow

Excellent idea!

[mcollovati]

So, let's proceed with the plan in the ticket description, and move the discussion about incompatible changes in patch release to #294

[mcollovati]

Since latest quarkus-hilla version 2.0.1 already targets Hilla 2.1.x, I propose to release version 2.1.0 (branch 2.1) and 2.2.0 (branch 2.2).
There will be no new quarkus-hilla 2.0.x because that would mean downgrading Hilla from 2.1.x to 2.0.x.