Hi Emily,
Thanks for bringing this up on the mailing list.
We've been discussing versioning often during the last few weeks and could have saved some time if we would start the thread before.
Better late than never, so thank you again :-)
Thanks Steve as well, I think I agree with your view.
I'm ok if we can support semantic versioning but I am very cautious about the way we want to implement it.
Follow up on the discussion last Tuesday and the minutes
Adding OSGi annotation dependency in APIs would require all signatures to be updated as well so we can check them.
What happens for other spec jars?
At Apache, there are API jars for pretty much all specifications. Adding to signature tests would require all apache API jars to be updated to add that OSGi annotation as well.
I'm not ok with adding an OSGi dependency and I'm not ok with the impact on the community.
Class retention: even if it's class retention it's still in the bytecode.
Deployment does not always happen at runtime (Quarkus for example).
And it's not uncommon to use tools like ASM, javasist, or other to read the bytecode where this annotation could be used for something specific, seriously impacting portability.
Do we want to open that door?
If we add OSGi Version annotation, why don't we add others?
That being said, let's step back a bit.
Let's say we want a semantic versioning in Jakarta for our APIs. First we would need to discuss and decide on the mailing list.
I would recommend not mixing with the "how to do it?"
On the "how", it looks like all the @Version with OSGi discussion comes from the tool we want to use (BND).
If the tool does not fit with our requirements, let's use/write another one.
A tool should help and not be a restriction.
Throwing a crazy idea to illustrate. Not saying it's good and we should follow this path.
We have had signature tests with signature definitions for ages.
Why don't we write a tool that does a comparison with a previous version of the signature definition?
Brainstorming but hope it helps