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

Request: Add Configuration Options for SDK Versions in Ceres SDK Components #104

Closed
2 tasks done
zeoowl-dev opened this issue Sep 29, 2023 · 4 comments · Fixed by #110
Closed
2 tasks done

Request: Add Configuration Options for SDK Versions in Ceres SDK Components #104

zeoowl-dev opened this issue Sep 29, 2023 · 4 comments · Fixed by #110
Assignees
Labels
@feature New feature or request @priority-medium
Milestone

Comments

@zeoowl-dev
Copy link

Is there an existing issue for this?

  • I have searched the existing issues

Describe the problem

I would like to request the addition of configuration options in the Ceres SDK Components to set the ceres.sdkcomponents.minsdk, ceres.sdkcomponents.targetsdk, and ceres.sdkcomponents.compilesdk values programmatically. Currently, these values are set to specific integers, but having the ability to configure them dynamically would provide greater flexibility and compatibility with different Android projects.

Rationale:

  • Dynamic configuration of SDK versions would allow developers to adapt the Ceres SDK Components to different project requirements.
  • It would make it easier to support a wider range of Android SDK versions without code modifications.
  • This feature would align the Ceres SDK Components with industry best practices for SDK version management.

Describe the solution

To implement this feature, we could introduce new configuration properties or methods that allow developers to specify the desired ceres.sdkcomponents.minsdk, ceres.sdkcomponents.targetsdk, and ceres.sdkcomponents.compilesdk values in their project's build.gradle or configuration files.

Additional context

No response

Code of Conduct

  • I agree to follow this project's Code of Conduct
@teogor teogor self-assigned this Sep 29, 2023
@teogor teogor added @priority-medium @feature New feature or request labels Sep 29, 2023
@teogor
Copy link
Owner

teogor commented Sep 29, 2023

Thank you for sharing your feature request with us! We appreciate your interest in enhancing the Ceres SDK Components and making it more adaptable to different Android projects.

I completely understand the importance of having dynamic configuration options for SDK versions. This would indeed provide greater flexibility and compatibility. It's also aligned with best practices for SDK version management.

I'll discuss this internally with our team to evaluate the feasibility and the best approach for implementing these configuration options. We want to ensure that any changes align well with the library's architecture and maintainability.

Please stay tuned for updates, and in the meantime, if you have any further thoughts or specifics you'd like to share regarding how you envision these configuration options working, we'd love to hear more about it.

@zeoowl-dev
Copy link
Author

Thank you for your quick response, and I appreciate your willingness to consider this feature request!

In terms of how these configuration options could work, I imagine having additional properties or methods in the Ceres SDK Components that developers can use in their Gradle scripts or configuration files. For example, something like:

ceres {
    sdkComponents {
        minSdkVersion = 21
        targetSdkVersion = 30
        compileSdkVersion = 30
    }
}

@teogor
Copy link
Owner

teogor commented Sep 29, 2023

Thank you for providing more insights into how you envision these configuration options working. Your proposed Gradle syntax makes sense and would certainly be a user-friendly way to handle SDK version configurations within project Gradle files.

As we continue to explore the best approach for implementing this feature, I'd like to bring up another possibility for your consideration. Instead of directly embedding these configurations within the project's Gradle scripts, we could introduce Gradle properties that users can set in their gradle.properties files.

For instance, users could add the following lines to their gradle.properties:

ceres.flags.sdk.min.version=21
ceres.flags.sdk.target.version=30
ceres.flags.sdk.compile.version=30

This approach offers a level of separation between the Ceres SDK Components and individual projects, potentially simplifying the implementation and making it easier for developers to manage these configurations, especially across multiple projects.

We'd love to hear your thoughts on this alternative approach and whether it aligns with your expectations. Your feedback is invaluable as we strive to make the Ceres SDK Components as user-friendly and adaptable as possible.

@zeoowl-dev
Copy link
Author

Thank you for considering the proposal. I agree that providing more flexibility in setting SDK versions can greatly benefit developers working with the Ceres SDK Components. To further expand on this, here are a few scenarios where different sets of SDK versions could be useful:

Default Configuration:

  • ceres.flags.sdk.min.version=24
  • ceres.flags.sdk.target.version=34
  • ceres.flags.sdk.compile.version=34

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
@feature New feature or request @priority-medium
Projects
Development

Successfully merging a pull request may close this issue.

2 participants