Roadmap Q4 2019 - Q1 2020
tmspzz opened this issue · comments
Hi all,
I am opening this issue to gather your feedback on a tentative roadmap that I've put together with the help of @Carthage/carthage
This roadmap will try to address the most pressing issues that Carthage is currently facing, and at the same time add clarity on where we think Carthage should be heading.
To my knowledge there wasn't a formal roadmap so far, and while Carthage has done very well up to this point I think this can help to give direction to the community of contributors. Also bare in mind that the success of the roadmap is dependent on your help as well.
I encourage you all to discuss the roadmap in a civil manner and provide as much feedback as you can. Also if you would like to help with the work on carthage on a regual basis or have means to support others to do so reach out to me on twitter @tmpz
Roadmap Q4 2019 - Q1 2020
So far Carthage has tried (🤕) to prefer stability of maintaining existing features against hastily adding (and possibly endangering/violating assumptions of previous features).
We think it's important to continue in this direction in an ecosystem where cloud CI (travis, circle, bitrise, github...) will swap major Carthage versions with no prompt.
That said we're not against adding new features as long as the behavior of existing ones is not changed. With that in mind there are the goals and low hanging features we have identified.
Goals
- Open http://carthage.github.io/ to host this roadmap. This will add transparency and give direction to the community of contributors
- Support XCFrameworks #2801, #2881, #2820 (Discussed further down)
- Support Catalyst #2801, #2868 (Discussed further down)
- Implement pubgrub resolver (Discussed further down)
- Improve the amount of documentation with per-use case scenarios
Support XCFrameworks
Supporting XCFrameworks is probably the most important new feature we should add. We think support can be added in either of two ways or both.
Per platform packing #2801, #2881
Allow packing per platform (i.e iOS + simulator). #2801
Many frameworks have different targets per platform so they won't be producing artifacts for other platforms.
Pack all platforms #2820
Allow packing all platforms (i.e iOS + TvOS + MacOS ...). Some frameworks have a universal target that supports all platforms.
In this case we want to offer both options of per platform packing and packing all platforms in one XCFramework.
Support Catalyst
Supporting Catalyst is just as important as XCFrameworks support. Here as well two different approaches are possible. Implicit support by build settings or explicit support by adding a new --platform. We feel support should be implicit rather that explicit, with explicit opt-out (e.g --no-catalyst)
Implement new resolver
While this is a bit of the stretch, there are some well known issues with both the plain old resolver and the --new-resolver that can be frustrating. To improve the current situation we think the way forward is to finishing resolver diagnostics #2519 and possibly implement Dart's Pubgrub solver https://medium.com/@nex3/pubgrub-2fb6470504f and https://github.com/dart-lang/pub/blob/master/doc/solver.md
Some of you might be thinking why not just use the swift-pm solver? That's is certainly a good idea but depending on swift pm in the past months have been quite painful and cause a few problems that we would rather avoid for the time being. That said, this still remains an option for the future.
💪
I’m the maintainer of SDWebImage, and Catalyst support is important for our users. On the 5.2.0 version we release Catalyst support on both CocoaPods/SwiftPM, but only without Carthage.
Personal idea:
With the release of Xcode 11, I guess that SwiftPM is for future, but not Carthage.
Carthage for me, the adcantage is that just using Xcode Project, which menas I can distribute open source project contains Assembly Language, C++ mixed in. Beyond limitation of that DSL like SwiftPM/CocoaPods. I find it really hard to port huge C++ codec library like ffmepg/libaom to CocoaPods, easy with Xcode and Carthage.
Currently SwiftPM still lack of Resource DSL Syntax to include any resourece other than code. And without support for dynamic libarary, etc. But I think we can hope for the future Xcode 12 with better SwiftPM, that is the time currect massive package manager on Cocoa/Cocoa Touch development will be unified. (Or more massive ? 😼)
What are the longer-term goals of Carthage? I've seen a posting on the Swift forums about integrating more with the Swift Package Manager, is that part of the plan?
For additional context / information: the current plan for the organization I work for is to use Carthage until the Swift Package Manager can meet our needs. Currently the only known issue holding us back from using the Swift Package Manager is pre-built binaries but we might also be limited by the ability to package our resources with our frameworks.
What are the longer-term goals of Carthage? I've seen a posting on the Swift forums about integrating more with the Swift Package Manager, is that part of the plan?
Aligning with SwiftPM to the point of making use of libSwiftPM (like we did in the past few releases) is certainly a goal but, as I mentioned, there have been issues related to continuing with that. We'll certainly should go back to it as some point.
For additional context / information: the current plan for the organization I work for is to use Carthage until the Swift Package Manager can meet our needs.
I think this is everyone's expectation and it's perfectly fine.
Maybe picking bug fixes from the https://github.com/nsoperations/Carthage fork might also be added to this roadmap
- I'm for the
Pack all platformsoption for XCFramework, if I can specify platforms that I need. Because building platforms that I don't need can be time-consuming. - I personally think that
adding a new --platformfor macCatalys is a way to go. Because it looks like a new platform, acts as a new platform. I personally always specify a platform for bootstrap/build commands - As for resolver, not sure what are the problems. never experienced any
https://www.jetbrains.com/lp/devecosystem-2019/swift-objc/ says that carthage is no good..
Thanks for your hard work maintaining Carthage. The roadmap looks great for the most part, it would be useful if the the following PR (#2774 ) could also be added to the Goals, in order to provide support for private binaries. If not, please let us know what are the outstanding concerns and how it can be mitigated.
Hello @Aranoledur this issue #2883 shows some current resolver problems, I don't know for sure but it seems the Pubgrub solver could help with something.
I think this roadmap could be followed more easily with the "Projects" feature of GitHub
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Any updates on this? Is there a release plan yet?
I'm not a Carthage user myself but wanted to applaud for the transparency 👏
We think it's important to continue in this direction in an ecosystem where cloud CI (travis, circle, bitrise, github...) will swap major Carthage versions with no prompt.
I think part of the issue is since the version number is 0.x.x, CI services think it's a minor change based on semver and expect things won't break. It might be good to find out how other dependency managers avoid this.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Twilio voice still required carthage to support .xcframework. So is it still in pipeline? Any ETA?
Same for libsodium :/