search

parse-community / Parse-SDK-iOS-OSX

The Apple SDK for Parse Platform (iOS, macOS, watchOS, tvOS)
https://parseplatform.org
Other
2.81k stars 871 forks source link

Remove alternative install options #1740

Closed dplewis closed 1 year ago

dplewis commented 1 year ago

New Feature / Enhancement Checklist

Current Limitation

Additional installation methods are outdated and causes a lot of overhead on development. With the removal of CocoaPod and Carthage the focus should be on SPM only. The current CI takes ~40 minutes. Integration testing doesn't exist. The release build can't compile on XCode 14 without removing arm64 support or converting to release build to xcframework.

Feature / Enhancement Description

parse-github-assistant[bot] commented 1 year ago

Thanks for opening this issue!

mtrezza commented 1 year ago

Continuing the discussion from https://github.com/parse-community/Parse-SDK-iOS-OSX/pull/1741#issuecomment-1746035804 here.

Above you wrote:

The release build can't compile on XCode 14 without removing arm64 support or converting to release build to xcframework.

What is the motivation to remove the assets? In other words, if we keep the assets, what's the implication? If the implication is more severe, then I'd suggest we remove the assets for now. The majority of developers doesn't need the assets I believe. If we later find a significant demand for assets we can look into how to add them, but this shouldn't stop the further SDK development.

dplewis commented 1 year ago

What is the motivation to remove the assets?

Should the CI ensures the project builds, compiles and test run or build a framework for release? We also build a Bolts-Objc framework for release too.

If we later find a significant demand for assets we can look into how to add them

If this happens we should handle assets properly. Converting the universal FAT framework into a xcframework and release it under SPM as a binaryTarget. I haven't tested the existing assets on Apple Silicon yet.

this shouldn't stop the further SDK development

The main goal is to get the CI down to 5-10 minutes. This project needs a lot of cleanup to get there. A quicker development cycle would be helpful for both review and running the project locally.

dplewis commented 1 year ago

@mtrezza We can close this. I have an idea to reduce CI times without removing the assets. We add building the StarterProjects to the CI. This is the best way to build and ensure the code works. The release build and releasing of assets should be handled in release-automated.yml.

mtrezza commented 1 year ago

But this issue was broader than only assets, right? We'd still want to remove relicts from Cocoapods, Carthage, etc? Also, if we cannot upgrade the CI and Xcode tests to newer Xcode versions, we'll have a problem soon. The CI runs on an old Xcode version and we'll soon loose support; I believe the CI currently runs on the oldest macOS runner that is still provided by GitHub Actions, because of the old Xcode version we need. Once that runner becomes unavailable we are in trouble. So if we can upgrade this, and have to remove the assets, I think it's a worthy tradeoff.

So this issue is about more than only the CI run time. I took the liberty to re-open, so we can decide on how to proceed.

dplewis commented 1 year ago

Also, if we cannot upgrade the CI and Xcode tests to newer Xcode versions, we'll have a problem soon.

Technically there should be a problem now as Swift 5.5 isn't installed on older version of Xcode. 

xcodebuild: error: Could not resolve package dependencies:
  package at '/Users/runner/work/Parse-SDK-iOS-OSX/Parse-SDK-iOS-OSX' is using Swift tools version 5.5.0 but the installed version is 5.2.0
dplewis commented 1 year ago

@mtrezza Now that you understand the situation how do you want to proceed?

mtrezza commented 1 year ago

If you confirm that my interpretation is correct, then I'd say let's drop assets and upgrade as much as possible. The argument for this is that if we don't upgrade now, every developer using the SDK will be affected, not just the ones using the assets, which I assume is a minority. So I'd choose the less impactful path going forward. If there are developers who require the assets who cannot switch to SPM, we'd need to look for a solution later on.

dplewis commented 1 year ago

Sounds good, I'll finish my checklist