Publish a bom?

[breedx-splk]

The other java-based projects (core, instrumentation, maybe even semconv?) publish a bom (bill-of-materials) that gradle can use to keep dependency versions aligned. As we continue to modularize the repository and publish more independent, smaller artifacts, this becomes increasingly important.

Is a bom a normal/standard thing to do for Android projects as well? I suspect so, since gradle is being used.

The goal is to prevent end-users and distros from having to specify individual versions. Specifying the version number for the bom should suffice.

[marandaneto]

yes, it is, okhttp for example has a bom

[LikeTheSalad]

I think it's fine, although for now we set the same version to all the modules so, are you referring to a future use-case where we might have separate repos related to OTel Android, each with their own version?

[marandaneto]

I think the goal of a bom is to use the very same version for all modules, so you know it's compatible.

future use-case where we might have separate repos related to OTel Android, each with their own version

if that's the case, then a bom isn't recommended.

[LikeTheSalad]

I think the goal of a bom is to use the very same version for all modules, so you know it's compatible.

Yeah, and I guess that's the reason I'm a bit confused about using it here, since all the modules are released with the same version. So it means that as long as the same version is used when adding all of them as dependencies, they will always be compatible. Though don't get me wrong, I don't have a strong opinion on not using BOMs, is just that I find them more useful when there are different versions involved.

Although I guess it could be handy for users who might be duplicating the same version across all the dependencies provided by this project, without using variables and/or version catalogs.

[marandaneto]

Although I guess it could be handy for users who might be duplicating the same version across all the dependencies provided by this project, without using variables and/or version catalogs.

That's why I find it useful as well, so I have to update only once/in a single place, and not be worried about incompatible versions instead of people doing it manually (first they would need to know that versions should match, maybe they don't).

[marandaneto]

I think it's not needed for v1 since this can be added later, and people can migrate to the BOM whenever they want.

[breedx-splk]

I think it's not needed for v1 since this can be added later, and people can migrate to the BOM whenever they want.

Technically true, but I'd like to see it. It makes to project feel more cohesive and mature IMO. Prefer to keep the tag for now, but maybe we don't let it be a showstopper. :)

[bidetofevil]

+1 to publishing a BoM. Folks that use this project shouldn't need to think about what versions of other dependencies that it has that it may want to import, e.g. semconv, SDK, etc. Using whatever versions the Android BoM stipulates would be the easiest thing to do for apps.

[marandaneto]

@breedx-splk An example of a simple script that might work such as https://github.com/getsentry/sentry-java/blob/main/sentry-bom/build.gradle.kts