Cocoapods: Release cycles too long?

[ileitch]

First, I'd like to say that I do not take CocoaPods for granted. Those who contribute are doing a fantastic job, and I benefit daily from your diligent work. Thank you!

I would however like to bring into question CocoaPods's release cycle length. On a number of occasions I've been caught out by bugs, only to discover they've been fixed in master for months, but not yet released.

One particular pain point for me seems to timing relative to Xcode releases. Currently with Xcode 10, this bug has been a problem for myself and a number of friends. It's a simple fix, yet it's held up by the enormity of other changes going into the 1.6.0 release. If my memory serves me correctly, this has been a recurring issue with Xcode releases, where CocoaPods lags behind the Xcode release considerably.

Given the number of bug fixes going in to each release, it seems to me that users would benefit from a shorter release cycle. Thoughts?

[amorde]

I actually agree, this sorta came up in our Slack recently. Part of the reason for this is the release process isn't as automated as it could be, so someone has to dedicate a decent amount of time to release CocoaPods + connected libraries like Xcodeproj

I do think this could be improved

[segiddins]

We also had requests last release cycle to slow things down, and give people a chance to try out the betas

[ileitch]

We also had requests last release cycle to slow things down, and give people a chance to try out the betas

Could that by a symptom of the number of changes in the release? Perhaps it's more daunting to try out the current betas. A quick smoke test of a beta shouldn't take more than 30 mins for most projects I'd imagine, perhaps people would be more eager to give them a try if they knew the changes were more minimal.

Another approach could be to continue with minor bug fix releases while large features are being developed? As @amorde mentioned, if the release process were more automated, there'd be less overhead in back-porting some critical bugs and cutting a minor release. That could allow for bug fix releases to be made in sync with new major Xcode releases, if needed.

Take #7708 for example. Our team is switching to Xcode 10, yet for some command-line builds we still need to use 9.4.1.

[amorde]

@ileitch While this doesn't solve the issue per se, I would recommend using Bundler to pin your build tools to the version needed for your project. That way you are free to use any commit / version etc. that makes sense for your project

[yvbeek]

It has been more than 5 months since the last release. The changelog for 1.6 is getting huge. I would recommend putting a freeze on the changes and only fix high priority bugs. CocoaPods 1.5.3 doesn't work properly with Xcode 10. Please release a new production version soon.

[dnkoutso]

@Zyphrax there was a beta 2 release that happened 10 days ago. It contains all of these fixes for Xcode 10. I understand you might want an official release (not beta) but we have to pace the change in 1.6.0 to ensure stability.

[jshier]

Given that it's been an additional 6 weeks with no new 1.6 beta, and the fact that 1.7 features have started being merged into master, isn't it time for a release? Or at least a new beta without the 1.7 features? I understand the intent of an extended beta process is to ensure fewer bugs, but unless there's an active beta process shipping fixes to test out, it seems that value is lost.

Additionally, I think people are frustrated with the bugginess of major releases mainly because there are so few patch releases to fix issues afterward. This means issues reported go unfixed in the public release for quite a while, which leads to the suggestion of a longer beta testing period to perhaps prevent those issues in the first place. Which leads to more issues found with the public release (especially after a major Xcode release) and the cycle continues.

As a non-contributor, I really only have two suggestions:

1. More patch releases to fix outstanding bugs. All too often these fixes get rolled into the next major update and frustrated users report duplicate issues or drop CP completely. Separating feature work from bug work would go a long way towards alleviating some of the support backlog as well as user frustration.
2. Releases timed with Xcode updates, especially major ones. 1.6 fixes quite a few issues with Xcode 10 yet most users aren't using it. Again, this could alleviate quite a lot of support backlog if the Xcode beta period was focused mainly on fixing the issues found. Whether this takes the form of a major release when the new Xcode ships or a series of patch releases over the beta period I don't know, though I'm not sure it matters.

[segiddins]

The problem is, no one really wants to do the work of backporting bug fixes to the stable versions

[jshier]

Perhaps a branching strategy would help there, if one can work with CP's dependencies. CP has had this release issue for a long time now and it seems fairly clear that a longer beta period doesn't help when the public version is incompatible with current version of Xcode. Something needs to change though, doesn't it?

[yvbeek]

It is really unfortunate that there isn't a 1.5.4 hotfix release containing just the Allow EXPANDED_CODE_SIGN_IDENTITY to be unset commit.

The latest stable (1.5.3) just isn't usable with Xcode 10(+). A lot of novice developers try to integrate a third party library into their app, but run into weird scripts issues with no clue what to do.

Although I am a Carthage user, I really appreciate the work done on CocoaPods, but I feel these long release cycles are killing the project.

[amorde]

the betas have been available with the --pre flag for quite a while, is using the beta not an option for you?

A difficult part of this for us is that there are really only a few people that actively contribute to CocoaPods, and they do so mostly during their free time. If you want to help, we'd love to have more contributors. A particularly time consuming task is triaging new issues.

I'll also make the same recommendation that I did here to use Bundler to manage CocoaPods. This makes it much easier to keep a consistent version across all developers on your project, and it makes installing or trying out beta versions much easier (don't even need a --pre flag). You can also use it to install other developer tools such as Fastlane.

[yvbeek]

@amorde I understand that there are only a few people working on this and like I said I appreciate all the work done on CocoaPods, that’s also why I try to expres my concerns.

Xcode 10 has been out for months now and the stable version is not working with it. This doesn’t only hurt CocoaPods, but third party libraries too. People want to try an example app, but run into weird script errors. Only a small percentage will dig deeper and try out the beta. A beta that has grown to a massive 1.6 version that not everybody will be able to use without making changes to their projects.

I fail to understand why a small hotfix release isn’t possible and wasn’t done months ago. It would have saved a lot of frustration. The fix has already been committed, it looks like all that is required is to create a hotfix branch, cherry-pick the commit and build a release, something that regular contributors can’t do.

[ileitch]

I'm the author of Periphery which is a tool that uses xcodebuild internally as a critical component of its operation. So many users are affected by the EXPANDED_CODE_SIGN_IDENTITY bug, that I actually ended up having to detect the error and print out a more helpful error instructing them to upgrade to 1.6.0 beta.

Many users initially outright reject using the beta version. They simply wanted to try out my tool, but now they're forced to consider upgrading to beta software that could affect the rest of their team. Some users perform the upgrade, but don't realize they also need to run pod install after the upgrade - I eventually had to explicitly mention that step in my custom error message. I hate to think how many people try my tool, see the error and just stop there.

I don't think the issue here is that it's difficult for people to try out the beta versions, Bundler certainly makes that super simple. The issue is that the average user isn't interested in trying the beta, nor do I think they should be forced to in order to obtain a fix for a show-stopper bug.

I think all that's really needed here is a bug-fix release to coincide with Xcode releases. I'm more than happy to help out with that.

I agree with @Zyphrax that the current release process is hurting CocoaPods. The current situation we have with 1.7.0 features being merged into a late-stage 1.6.0 beta is a huge red flag for me. It also invalidates a lot of the bug testing work people have done on the prior betas.

[dnkoutso]

I've been wanting to respond here for a while.

The issues raised here are very valid. As a core contributor I can understand the frustration here.

There are a few points here to make as to why releases are "slow" that are outside the standard (but valid) "CocoaPods is maintained by the free time of individuals who support it".

1) Very importantly there are only 1 or 2 people in the world who know how to make a CocoaPods release and I am not one of them. I have started https://github.com/CocoaPods/CocoaPods/pull/8440 and I am actually in the process of releasing 1.6.0.rc with a hopeful fast follow of 1.7.0.beta. This will finally provide instructions for other maintainers to be able to release as currently it is gated by one or two people and their free time to do so.

2) There are no 1.7.0 features being merged into 1.6.0 beta. There is a stable branch 1-6-stable. It is very true that 1.7.0 development occurred very fast on master without having 1.6.0 released fully. We had to backport a few PRs to get things right and 1.6.0 final hasn't been released yet. We should do proper converge branches in the future and not having to deal with this again.

3) CocoaPods required heavy infrastructure investment in order to facilitate new features and support for large scale projects (see build settings re-write for example in 1.6.0). This is why things moved a slower in order to ensure there are no regressions for folks. I am personally able to maintain it for my projects (using Bundler) but that might not be true for others so I pushed for slower release cycles as to avoid "breaking the world" given that there are only a few maintainers in the project. I want to avoid such huge responsibility as CocoaPods currently has ~13M downloads (tracked by rubygems.org) and gets ~250K a month with a few pods being integrated by hundreds of thousands of apps.

Like I said, the concerns raised here as super valid and I am pushing currently to get out of the 1.6.0 hole we've dug ourselves into. I expect to have an RC very soon (aiming for this week) as I am going through the release process myself and document how it gets done.

Once I make a release and I merge #8440 I will close this and proceed with wrapping up 1.7.0.beta.1 while this time not allowing anything in 1.8.0 to get in the way.

[yvbeek]

@dnkoutso Thank you for providing these insights.

CocoaPods required heavy infrastructure investment in order to facilitate new features and support for large scale projects (see build settings re-write for example in 1.6.0). This is why things moved a slower in order to ensure there are no regressions for folks. I am personally able to maintain it for my projects (using Bundler) but that might not be true for others so I pushed for slower release cycles as to avoid "breaking the world" given that there are only a few maintainers in the project

This makes it all the more confusing to me why a small patch wasn't released to fix Xcode 10 support. Basically "the world" is broken at this moment, unless you use the beta version, which is unacceptable for production scenarios.

Again, I really appreciate all the time that people contribute to this project. I simply don't understand why beta versions were released when a small patch release could have resolved a problem that is going on for almost 8 months now.

[segiddins]

Because no one did the release, it’s honestly as simple as that

[yvbeek]

@segiddins Yes, why though? Is it more difficult than a beta release? I believe it takes only one commit (small tweaks to the embed resources script) to fix Xcode 10 support.

[dnkoutso]

@Zyphrax Yes mostly because I was unable personally to make a release. This is about to change.

[segiddins]

It just takes time to do a release. The core team for cocoapods is small, the list of active maintainers is even smaller, and none of us get paid to do this. None of us got around to it.

[yvbeek]

@segiddins Yes, let me please put emphasis on that I really appreciate the hard work you guys do. I only find it unfortunate that there was work being done on beta releases, when there are so many people having issues with 1.5.3.

I'm providing this feedback because I think time would have been better spent on a 1.5.4 version (patch) instead of 1.6.0 beta 1. But most of all, because Xcode 10 support is still an ongoing issue unless you use the beta version.

But no need to spend more words on this, I look forward to the next production release!

[amorde]

Yes, in hindsight a 1.5.4 release would have been better. I think we were in a state of "almost ready to release 1.6.0" for so long that a 1.5.4 release didn't seem necessary, but that might just be my personal perception. Going forward I hope we can do smaller patch releases more often.

[ileitch]

Documenting the release process is a major first step to improving the situation 👍
Beyond that, hopefully some automation is enough to make releasing minor versions a more common occurrence.

[dnkoutso]

Released 1.6.0.rc.1.

[dnkoutso]

Released 1.6.0.rc.2. Things are getting easier for me to make releases! :D

[dnkoutso]

PR for release instruction has moved to Rainforest repo https://github.com/CocoaPods/Rainforest/pull/80

[dnkoutso]

I have successfully released 2 versions so far. This will now be closed as there are instructions and we will ask different maintainers to try them out!

Closing for now and I expect 1.6.0 final this week unless an issue arises with RC2.