Would like to setup Carthage Deploy artifacts on Travis

[KyleLeneau]

Hey @groue ,

This is mostly a question for you on how I should proceed with something I have been thinking of. To help with the Carthage support I would like to change the release process so that when releases are tagged there is a proper release page in Github with the Changelog for the tag and importantly uploaded build artifacts from Carthage deploy step... In order to do this though I need to setup travis to use a "machine" / "ci" user and access token to interact with the API. I wanted to get your opinion on how to proceed with that and if you have any ideas on how that could be setup and maintained.

I have done this for my current company and posted with Github, Gitlab using CircleCI or Bitrise or homegrown scripts so I am not worried about the technical work. I have limited use with Travis so it will take some learning but I know how to do the rest. I am probably going to follow this guide a bit and tweak as I learn Travis CI: https://github.com/Carthage/Carthage#use-travis-ci-to-upload-your-tagged-prebuilt-frameworks

Anyways, wanted to get your opinion. Also, I didn't know the best way to connect with you on this so I hope an issue works out, feel free to close this or connect with me another way.

Thanks,
Kyle

[groue]

Hello @KyleLeneau,

Unlike CocoaPods which is a tool which helps both library users and library authors, Carthage expects library authors to do its job, and does a poor job at helping library users. Carthage users who want GRDB, currently, fork the GRDB repo, and tweak the meat until Carthage can do its job.

I don't like this tool, and I don't like spending time and energy they should spend. My job is providing a SQLite library, with documentation for reliable installation methods. Carthage is not one of them: it is described as "not supported" in the main README.

I'm sorry they're understaffed, and don't listen to reasonable feature requests. That's not my problem.

End of the rant.

Now the answer you ask for: since I don't want to maintain workarounds for Carthage, I'll need a maintainer who is committed to long-term support whenever such workaround ships in the main repo. I'm bloody serious when I say "long-term support".

[groue]

There are only two real fixes to this issue, of course:

• Fix Carthage
• Stop using Carthage until it is fixed

I really don't like this pressure to integrate workarounds just because people insist on using a broken tool.

[groue]

For f***'s sake, we'd need to produce binaries for each supported Xcode version/Swift ABI (reminder: we're still supporting Xcode 9.3+) The more I think about it, the crazier I find this idea.

[groue]

Oh, and how many people have to implement those workarounds, just because Carthage maintainers do not? Doesn't it sound like an unfortunate energy spill? Are contributors of open-source libraries supposed to spill their time because they are nice? Who will maintain the script as new Xcode and Swift version ship? Who will support users who have troubles, and not only acknowledge, but FIX their troubles?

The number of open issues in GRDB is usually very low, for three reasons: this library is maintained, does not over-promise, and it is possible to fix user issues because all documented stacks are reliable from top to bottom. This is my recipe for a trustable and sustainable open source library, with as few opportunities as possible for maintainers to be burnt, and as few opportunities as possible for users to be disappointed.

[groue]

With my framing of the topic, one can wonder where is the room for experimentation, where is the "edge" version of the lib, how it is possible to move on, how we can provide to the users who are willing to move fast and break things their fix of technical hotness.

I'm perhaps over cautious, in my attempts at keeping the complexity of the project under (my?) control.

I'm wondering what people with more experience of open source think. May I ask for your advice, @KyleLeneau, @freak4pc, @SD10?

[SD10]

We currently use GRDB + Carthage by forking this project and tweaking it as needed. This is something I've just grown to accept with Carthage.

Everyone has different opinions on this topic, but I don't believe it's the job of library maintainers to work around shortcomings in a "package manager". Fwiw, we're actually migrating to CocoaPods because of this.

I'm sorry they're understaffed, and don't listen to reasonable feature requests. That's not my problem.

I'm very bitter in regards to how they've handled this as well.

For f***'s sake, we'd need to produce binaries for each supported Xcode version/Swift ABI (reminder: we're still supporting Xcode 9.3+)

This isn't a scalable solution without ABI stability. I believe we provided prebuilt binaries for Moya and then decided to abandon this approach because it led to so many problems/confusions by users.

[freak4pc]

I side with @groue.
The worst side of supporting users as an Multi-OSS -projects maintainer is supporting Carthage users. It's absolutely riddled with issues that are beyond the scope of a "stay out of my way" style dependency manager.

When the project is small I could see how supporting Carthage via patches is somewhat OK, but for a large project like this, with backwards compatibility as early as Xcode 9.3, supporting Carthage beyond the "defaults" would be impossible. (Or just really not worth it, mostly).

Pre-built binary are all nice and fun but until there's ABI stability they are practically useless to anyone not using the same version as the prebuild binary.

[groue]

Many thanks to @SD10 and @freak4pc for your experience and precious feedback!

@KyleLeneau, I hope those balanced voices did not cool you down. Let me try to sum up the situation:

Carthage creates a strong pressure on repository maintainers, who have to solve various support issues, without any guarantee of success. Carthage is not an easy toy, and not a one-size-fits-all solution. It's made for power-users and people who are willing to support themselves. Those people currently fork the GRDB repository, and perform their own setup and maintenance.

This may be the best option for you, too, at the present time.

I'll help supporting Carthage (I already did: #408, #202, groue/sqlcipher#1), but not by committing myself and GRDB to official Carthage support and maintenance. I can only change my mind when someone emerges and takes over both.

[KyleLeneau]

Thanks for all the feedback, I am finding the 1) updating carthage (contributing to the source) is going to take longer, it's on my goals to do but to make what I want to work I need to re-write how Carthage manages the files... 2) for my personal project that is using GRDB I find it easier to just use carthage to manage the submodules and then setup a workspace.