Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update Kujaku to Use Mapbox SDK Version 10.xxx #382

Open
Aleem92 opened this issue Jan 27, 2025 · 3 comments
Open

Update Kujaku to Use Mapbox SDK Version 10.xxx #382

Aleem92 opened this issue Jan 27, 2025 · 3 comments
Assignees
Labels

Comments

@Aleem92
Copy link

Aleem92 commented Jan 27, 2025

Mapbox has introduced significant updates to their SDK distribution model, impacting the way dependencies are managed. Currently, the Kujaku library uses Mapbox SDK version 9.7.1, which is not publicly available and requires authentication with a token to download dependencies. This introduces additional complexity to the build process.

However, Mapbox has recently moved their Android SDK artifacts to Maven Central, making them publicly accessible and removing the need for authentication. These changes are implemented in the newer versions of the SDK (10.x.x and 11.x.x).

Benefits of Migration:

  • Simplified dependency management: Eliminates the need for authentication tokens in the gradle file.
  • Access to the latest features and improvements introduced in Mapbox SDK versions 10.x.x and above.
  • Enhanced compatibility and support for modern Android development practices.

Action Items:

  • Update the Mapbox SDK dependency in the Kujaku library from version 9.7.1 to version 10.x.x.
  • Migrate the existing outdated classes to align with the supported version 10.x.x.
  • Test the updated library to ensure compatibility and functionality with the new SDK version.
@pld
Copy link
Member

pld commented Jan 28, 2025

Looks good, is there a reason to upgrade to 10.x and not the latest version? If it does not introduce too many more changes (ie if it adds <0.5days additional work) I'd ugprade to the latest release instead of 10.x

@Aleem92
Copy link
Author

Aleem92 commented Jan 28, 2025

Looks good, is there a reason to upgrade to 10.x and not the latest version? If it does not introduce too many more changes (ie if it adds <0.5days additional work) I'd ugprade to the latest release instead of 10.x

Thank you for your feedback. The initial suggestion to upgrade to version 10.x.x was to minimize the scope of migration changes, as the transition from 9.7.1 to 10.x.x already introduces significant API updates. Taking an incremental approach ensures a smoother migration and reduces the risk of breaking changes.

That said, upgrading directly to the latest version (11.x.x) is a viable option. It provides additional features, bug fixes, and long-term benefits. I can update the plan accordingly if this aligns better with our objectives.

@pld
Copy link
Member

pld commented Jan 29, 2025

What 10 version are you targeting, and what is the estimated timeline for that upgrade?

How much additional time do you estimate to upgrade from the current version to the latest version?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants