chore: release version 2.5.0

[jagalindo]

Summary

• Bump Python (uvlparser), Java, and JS parser versions to 2.5.0
• Adds test suite for Python, JS, and Java parsers
• Adds support for arithmetic level, feature cardinality, composition, and more UVL test models

Test plan

• CI grammar tests pass (Python, JS, Java) via test.yml
• Python package publishes to PyPI as uvlparser==2.5.0
• Java package publishes to Maven Central as 2.5.0
• JS package publishes to npm as 2.5.0

[jagalindo]

@SundermannC A review approval is now required to merge this pr and automatically (if everything works as expected) generate the release 2.5.0 of the parsers

[SundermannC]

Thanks a lot for preparing all of this. This looks very good overall. I have two concerns though, which both should be easy to resolve.

1. It seems that you have included the test models directly in the repository. In the java-fm-metamodel, we included the uvl-models repo as submodule to sync test cases across different and avoid duplicate incarnations of the dataset. I think that would also make sense here.
2. The new version number (2.5.0) does not really make sense for the Java version, which is currently at 0.4.1. Also, I think given we are currently changing a lot and guarantee no backwards compatibility (even though we try), I think it makes sense to release a 0.X.Y version for the UVL parser. Hence, I would suggest to do a 0.5.0 release for uvl-parser and java-fm-metamodel next. What do you think?

[jagalindo]

Thanks a lot for the careful review and the positive feedback. It is much appreciated 🙂

Regarding your points:

Test models / submodule
I understand the motivation behind using the uvl-models repository as a submodule to keep test cases in sync and avoid duplication.

Personally, I’m a bit hesitant about relying on
git submodules, as they tend to add friction in practice (extra steps when cloning, updating, CI issues, etc.), especially for contributors who are less familiar with them. That said, I do agree with the underlying goal of avoiding divergence of test datasets.

For this PR, I’d prefer to keep the test models as they are and address artifact sharing or synchronization as a separate follow-up step, so we can discuss and set that up more deliberately without coupling it to the current changes.

Versioning
That’s a fair point. My initial idea with 2.5.0 was to align the parser versions across the different implementations and signal that this is a significant step forward. Given that we are indeed introducing breaking changes, my instinct was to eventually move towards a 1.x.x scheme rather than staying indefinitely in 0.x.

One additional constraint worth mentioning is that, on the Python side, we cannot go below 2.1.0 due to existing releases and downstream dependencies, which also motivated the attempt to keep versions roughly in sync. That said, I do see the argument for keeping the Java artifacts in a 0.X.Y scheme while the API is still in flux, and a 0.5.0 release for both uvl-parser and java-fm-metamodel is a reasonable and conservative choice if we prefer to decouple the versioning across implementations.

Happy to adapt this PR accordingly, let me know how you’d prefer to proceed on both points