Do you have a plan to support SwiftPM and Carthage?
TofPlay opened this issue · 6 comments
Hi,
An interesting collection of components
Do you have a plan to support SwiftPM and Carthage?
Here some links that help for Carthage:
- Ruthlessly Simple Dependency Management with Carthage
- Carthage Tutorial: Getting Started
- Making Carthage-compatible Frameworks with Swift
- Swift Cross Platform Framework
👍
And others for SwiftPM:
- Clang 4.0 documentation - Modules
- Package Manifest File Format Reference
- Swift Package Manager Community Proposal
When your components are compatible on your README.md can add 
Hi, thx.
Seems like you know a bit about Carthage. I was researching CocoaPods this morning but it seemed like a lot of work. Dependency managers are awesome and one must use them.
What about Sem Ver? I mean the Element project changes really fast in order to be able to "turn on a heel" So i chickened out of "Major Minor Patch" and just went: 0.0.0-alpha1 and then i will iterate alpha2, alpha4 etc. Until people start to depend on it which i will need to change strategy. Question 1: Is Carthage compatible with versioning number such as this? Or must I Start proper Sem Ver when using Carthage? If the later is true that means I will be at v34.0.0 before the month has finished. I could dev on feature branches of course but then I fear I would get the "parallel universe syndrome".
I was looking into git subtrees as a strategy. Like have a public repo that pulls data only when a version is due. But it also had its drawbacks.
Question 2: So if Carthage or CocoaPods support my versioning strategy then ill press on and do the research tomorrow.
Question 3 I researched Swift package management the other day, it seemed to me like it was just a Package.swift file. But seems to only support Sem Ver at this point?
Hi,
Answer 1: Yes Carthage is compatible with semver. we use it for our own components. And it's sure you need to have a clear management of the version of your components. In the development process your not suppose to increment the major version for each commit. First you create a branch, you commit your change on this branch and when this feature is fully functional your increment the version: Major if this version is break the compatibility with the previous version, minor if you add some functionality backwards-compatible with the previous version, patch if you just fix some bugs without change the public API.
Answer 2: At first we used CocoaPods. With CocoapPods we've had a big problem. They forced us to migrate to a new version when we were not ready for that. The migration on the new version was done in disaster because no more projects could build. The new version of CocoaPods was incompatible with our version and corrupted our Xcode projects. It took several days to clean up our components and projects. That create a big prejudice with regard to our customers. With Carthage this kind of incident can not happen. It does not hack Xcode projects, no risk to corrupt Xcode project, and does not have a centralized management of components. No risk that Carthage will forced you to install a version if you are not ready for that. You do what you want when you are ready. You also do not need to master a language like Ruby and it's environment to use it. No need for an iOS developer to be a Ruby developer too. With Carthage you just have to install one binary and one framework.
Answer 3: SwiftPM support semver. The difference with CocoaPods and Carthage is that it is the official manager components for Swift and it is written totally in Swift. If you make components that need to run on Linux it must be compatible with SwiftPM. For components for macOS, iOS, WatchOS or tvOS it's simpler for now to stay with Carthage. SwiftPM is evolving very quickly and the best is coming. The team that works on it does an amazing job. SwiftPM is the future. It will replace CocoaPods and Carthage. But before being able to migrate our projects on SwiftPM it is necessary that all the components support it. That will take time but it is inevitable.
Thx for your personal experience with Cocoa pods. Its hard to find honest information about which dependency manager to use.
I'm still puzzled about sem ver. Like. Major = Api breaks old Major, Minor = feature addition, Patch = fix
The problem is that i'm constantly breaking old API to move fast and be able to experiment. So i will have to bump Major very often to honour Sem ver rules.
I see Atom took a different approach when in alpha:
They bumped only Minor very rapidly before major turned 1. So basically:
0.1.0
0.2.0
0.3.0
0.4.0
...a couple of weeks later
0.78.0 <--(breaking things and moving fast)
...a couple of months later:
0.229.0
the next day:
1.0.0
...a couple of weeks later. (post alpha)
1.2.16 <-(moving slow and honouring sem ver rules)
Whats my problem with bumping Major rapidly? Well, Users think that going from 1.0 to 2.0 will have many new features added etc. The public perception of such a bump. But in sem ver it represents only breaking backwards compatibility.
So with the information i currently have i will need to Either do as Atom did. Which is not stricly sem ver.
Or do as I do now. 0.0.0-alpha1 And then just bump the number after alpha. Until im willing to stop breaking backward compatibility.
I found this in some old notes about sem ver: "version number is less than 1.0.0, it’s considered to be a beta version, and minor number increases may include backwards incompatible changes."
So I will start splitting up the repo into Separate chunks and add Carthage. I doubt i will ever reach 1.0.0. Due to the nature of how sem ver works.
Trying to add Carthage support. It currently works but what I really want is nested framework support for carthage. Any experience with this? Like:
Framework A needs Framework B Which needs Framework C.
Wrote an article covering Carthage + nested framework: http://stylekit.org/blog/2017/02/03/Carthage-and-nested-frameworks/
So this now has Carthage support. SPM support as well.