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

Please consider making separate code-connect repositories for different technologies #33

Open
SwiftNativeDeveloper opened this issue Apr 25, 2024 · 2 comments
Labels
under discussion The Code Connect team is currently discussing this request

Comments

@SwiftNativeDeveloper
Copy link

Please make separate libraries and repositories for the different platforms you plan to support.

code-connect-react
code-connect-swift
and so on

For teams that use the semantic versioning of libraries to determine change, impact analysis, when to trigger security/privacy/bug reviews, and finally make a decision to upgrade or not, having a single combined library causes extra work on the teams consuming this SDK.

Most vendors that think they can release an update to all platforms at once put everything all in one place. Doing so will inevitably result in semantic version update to something like the SwiftUI support, but no real change or update because there was a fix or change applied to a different platform within the same repository. This can have significant impact to teams using your products.

I posted the following on another dependency I was looking at on why this matters so much.

Compatibility - Semver defines version numbers in a way that communicates compatibility. Major version increments signify incompatible API changes, minor version increments indicate backward-compatible feature additions, and patch version increments represent backward-compatible bug fixes. Since iOS and Android platforms often have distinct APIs and feature sets, changes made to one platform may not be directly compatible with the other. Maintaining separate repositories would allow each platform to follow its own versioning scheme, accurately reflecting compatibility and avoiding confusion for users and developers.

Release Management - Semver principles guide the release process by specifying how version numbers should be incremented based on the nature of changes. Following semver allows users and developers to understand the significance of each release and determine whether an update is necessary. In a combined repository for iOS and Android codebases, it may be difficult to apply semver consistently, especially if changes are platform-specific or if one platform receives updates more frequently than the other. Separate repositories provide a clearer framework for versioning and release management, enabling each platform to maintain its own versioning history and release schedule.

Clear Communication - Semver promotes clear communication of changes between different versions of software. By following semver guidelines, developers can convey the nature and scope of changes effectively through version numbers. When iOS and Android codebases are combined in a single repository, it may be challenging to communicate changes accurately, particularly if version numbers do not reflect platform-specific updates. Separate repositories enhance communication by allowing each platform to have its own versioning scheme, ensuring that users and developers can easily understand the significance of updates for their respective platforms.

@tomduncalf-figma
Copy link

Hey @SwiftNativeDeveloper, just to let you know we are discussing this internally as you raise some great points. We'll keep you updated. Thanks

@tomduncalf-figma tomduncalf-figma added the under discussion The Code Connect team is currently discussing this request label May 3, 2024
@SwiftNativeDeveloper
Copy link
Author

FWIW, additional comments.

I just went through an SBOM and product security analysis with my security colleagues for another app. This came to mind as another good reason to split the projects--so the downstream app teams have an easier time filling out their software bill of materials for what gets downloaded when the app is built via swift package manager.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
under discussion The Code Connect team is currently discussing this request
Projects
None yet
Development

No branches or pull requests

2 participants