Not sure if there is an answer that works for all. I would put a version
on the exports - not putting one usually looks like a mistake :)
An API should not be in an unstable state for a long time - hopefully
you can validate your API before you do the first release. If you really
need a release to validate, I would go with major version being 0 -
clearly stating that things can break.
But again, I think the mistake is to have it for too long in unstable.
Usually, if you have a stable API and things need to be fixed, you can
do that and deprecate/phase out parts of the old API.
Waiting indefinitely to mark an API stable will not help with that.
Regards
Carsten
On 7/23/2025 6:01 PM, Robert Munteanu wrote:
Hi,
On Mon, 2025-07-21 at 09:17 +0200, Konrad Windszus wrote:
Hi,
In the context of SLING-12861[1] the question arose how to promote an
unstable (0.x versioned) package version to a stable one without
breaking all consumers.
IIUC all bundle and package versions having major version 0 are
considered preliminary [2] by baselining and therefore will never
emit any errors even when modifying the API in a non backwards
compatible way without modifying the version.
I raised a ticket with Bnd[3] but while waiting for an answer there I
would like to know how the process used to be for other Sling modules
in the past.
Thanks in advance for any input.
I am not aware of history but I am in the same situation with the OAuth
Client bundle which exports packages as 0.1 and marks them all as
@ProviderType to generate narrow import ranges [4].
Now I wonder if exporting packages without a version would be better
rather than setting 0.x versions.
Thanks,
Robert
[4]:
https://github.com/apache/sling-org-apache-sling-auth-oauth-client?tab=readme-ov-file#apache-sling-oauth-20-client-with-oidc-support
--
Carsten Ziegeler
Adobe
cziege...@apache.org
