Add plugins version

[ank27]

Summary of changes

• Added plugins version v1.1.3 (https://github.com/mapbox/android-sdk-versions-plugin)

User impact (optional)

Pull request checklist:

• Briefly describe the changes in this PR.
• Include before/after visuals or gifs if this PR includes visual changes.
• Write tests for all new functionality. If tests were not written, please explain why.
• Optimize code for java consumption (@JvmOverloads, @file:JvmName, etc).
• Add example if relevant.
• Document any changes to public APIs.
• Apply changelog label ('breaking change', 'bug 🪲', 'build', 'docs', 'feature 🍏', 'performance ⚡', 'testing 💯') or use the label 'skip changelog'
• Add an entry inside this element for inclusion in the mapbox-maps-android changelog: <changelog>Added sdk versions plugin v1.1.3.</changelog>.
• If this PR is a v10.3 release branch fix / enhancement, merge it to main firstly and then port to v10.3 release branch.

Fixes: < Link to related issues that will be fixed by this pull request, if they exist >

PRs must be submitted under the terms of our Contributor License Agreement CLA.

[yunikkk]

Btw ktlint check fails on CI

[ank27]

Btw ktlint check fails on CI

Yeah, that's benchmark-check. it will be fixed by internal ticket.

[kiryldz]

@ank27 shouldn't we actually add generated asset files as part of this PR?

[kiryldz]

@ank27 shouldn't we actually add generated asset files as part of this PR?

As discussed offline seems answer is no.
However we need to think of some concrete steps how / when to populate correctly VERSION_NAME inside gradle.properties so that version obtainable in runtime will be the correct one when we perform the release of our SDK.

I believe correct solution for now will be updating our release template with a step of not forgetting to specify correct version in gradle.properties when we're cutting a release but perhaps there's a better way cc @mapbox/maps-android

[pengdev]

currently we only apply the version plugin to the sdk module, however we could discuss if we want to add it to all our plugins, as mentioned in https://github.com/mapbox/android-sdk-versions-plugin#about-android-sdk-versions-plugin

All Mapbox android SDK modules that incorporate the Telemetry SDK and meant to be released as libraries(artifacts) should apply this plugin to facilitate the Telemetry SDK access all Mapbox library versions at run time.

[ank27]

As discussed offline with @nagineni

we should be adding the dependency only to the core module.

We can discuss more if we want to add it to plugins as well, but we will iterate this in future releases. currently, core doesn't have a parsing logic in place and they are working on another solution as well.

[pengdev]

@ank27 shouldn't we actually add generated asset files as part of this PR?

As discussed offline seems answer is no. However we need to think of some concrete steps how / when to populate correctly VERSION_NAME inside gradle.properties so that version obtainable in runtime will be the correct one when we perform the release of our SDK.

We do update the VERSION_NAME inside our CI when building the release tag:

mapbox-maps-android/.circleci/config.yml

Line 170 in b05fa61

sed -i -e "s/^VERSION_NAME=.*/VERSION_NAME=${CIRCLE_TAG:9}/" gradle.properties

, however I also think we should validate if the version asset file is generated correctly with our CI before the release.

I believe correct solution for now will be updating our release template with a step of not forgetting to specify correct version in gradle.properties when we're cutting a release but perhaps there's a better way cc @mapbox/maps-android

We could document updating the version name in gradle.properties if we release manually, but I guess do it anyway since we need to correct version to publish the artifacts.

[pengdev]

LGTM, could we test it out and validate the asset file is generated correctly?

[ank27]

LGTM, could we test it out and validate the asset file is generated correctly?

Yes, Asset file is generated correctly.
@tarigo @nagineni can you confirm this is correct name that core wants?

[tarigo]

LGTM, could we test it out and validate the asset file is generated correctly?

Yes, Asset file is generated correctly. @tarigo @nagineni can you confirm this is correct name that core wants?

No, unfortunately this is not correct. But it's a good point to consider in the new plugin: project.name is not enough, probably we have to use ext.mapboxRegistrySdkName or POM_GROUP_ID+POM_ARTIFACT_ID to build SDK name.

[pengdev]

project.name is not enough, probably we have to use ext.mapboxRegistrySdkName or POM_GROUP_ID+POM_ARTIFACT_ID to build SDK name.

These information are all available in the sdk-registry plugin, probably we can combine the versions plugin to the sdk-registry plugin by adding a separate task?

[tarigo]

project.name is not enough, probably we have to use ext.mapboxRegistrySdkName or POM_GROUP_ID+POM_ARTIFACT_ID to build SDK name.

These information are all available in the sdk-registry plugin, probably we can combine the versions plugin to the sdk-registry plugin by adding a separate task?

Good idea!