Blog post for 1.1.0 release #135

benasher44 · 2016-09-12T15:57:28Z

CocoaPods 1.1.0 release blog post. Improvements mentioned:

Extension and framework improvements
Xcode 8 support
Error handling improvements

More?

benasher44 · 2016-09-12T15:58:42Z

I haven't been able to run rake serve:drafts successfully yet. I hit this error:

blog.cocoapods.org [basher_1.1.0] $ rake serve:drafts --trace
** Invoke serve:drafts (first_time)
** Execute serve:drafts
Starting the server locally on http://localhost:4000
bundle exec jekyll serve --watch --drafts --port 4000
Configuration file: /Users/benasher/Code/Ruby/blog.cocoapods.org/_config.yml
            Source: /Users/benasher/Code/Ruby/blog.cocoapods.org
       Destination: /Users/benasher/Code/Ruby/blog.cocoapods.org/_site
      Generating... 
  Liquid Exception: undefined method `[]' for nil:NilClass in _layouts/post.html
jekyll 2.5.3 | Error:  undefined method `[]' for nil:NilClass
rake aborted!
Command failed with status (1): [bundle exec jekyll serve --watch --drafts ...]
/Users/benasher/.rvm/gems/ruby-2.0.0-p648/gems/rake-10.4.2/lib/rake/file_utils.rb:66:in `block in create_shell_runner'
/Users/benasher/.rvm/gems/ruby-2.0.0-p648/gems/rake-10.4.2/lib/rake/file_utils.rb:57:in `call'
/Users/benasher/.rvm/gems/ruby-2.0.0-p648/gems/rake-10.4.2/lib/rake/file_utils.rb:57:in `sh'
/Users/benasher/.rvm/gems/ruby-2.0.0-p648/gems/rake-10.4.2/lib/rake/file_utils_ext.rb:37:in `sh'
/Users/benasher/Code/Ruby/blog.cocoapods.org/Rakefile:28:in `block (2 levels) in <top (required)>'
/Users/benasher/.rvm/gems/ruby-2.0.0-p648/gems/rake-10.4.2/lib/rake/task.rb:240:in `call'
/Users/benasher/.rvm/gems/ruby-2.0.0-p648/gems/rake-10.4.2/lib/rake/task.rb:240:in `block in execute'
/Users/benasher/.rvm/gems/ruby-2.0.0-p648/gems/rake-10.4.2/lib/rake/task.rb:235:in `each'
/Users/benasher/.rvm/gems/ruby-2.0.0-p648/gems/rake-10.4.2/lib/rake/task.rb:235:in `execute'
/Users/benasher/.rvm/gems/ruby-2.0.0-p648/gems/rake-10.4.2/lib/rake/task.rb:179:in `block in invoke_with_call_chain'
/Users/benasher/.rvm/rubies/ruby-2.0.0-p648/lib/ruby/2.0.0/monitor.rb:211:in `mon_synchronize'
/Users/benasher/.rvm/gems/ruby-2.0.0-p648/gems/rake-10.4.2/lib/rake/task.rb:172:in `invoke_with_call_chain'
/Users/benasher/.rvm/gems/ruby-2.0.0-p648/gems/rake-10.4.2/lib/rake/task.rb:165:in `invoke'
/Users/benasher/.rvm/gems/ruby-2.0.0-p648/gems/rake-10.4.2/lib/rake/application.rb:150:in `invoke_task'
/Users/benasher/.rvm/gems/ruby-2.0.0-p648/gems/rake-10.4.2/lib/rake/application.rb:106:in `block (2 levels) in top_level'
/Users/benasher/.rvm/gems/ruby-2.0.0-p648/gems/rake-10.4.2/lib/rake/application.rb:106:in `each'
/Users/benasher/.rvm/gems/ruby-2.0.0-p648/gems/rake-10.4.2/lib/rake/application.rb:106:in `block in top_level'
/Users/benasher/.rvm/gems/ruby-2.0.0-p648/gems/rake-10.4.2/lib/rake/application.rb:115:in `run_with_threads'
/Users/benasher/.rvm/gems/ruby-2.0.0-p648/gems/rake-10.4.2/lib/rake/application.rb:100:in `top_level'
/Users/benasher/.rvm/gems/ruby-2.0.0-p648/gems/rake-10.4.2/lib/rake/application.rb:78:in `block in run'
/Users/benasher/.rvm/gems/ruby-2.0.0-p648/gems/rake-10.4.2/lib/rake/application.rb:176:in `standard_exception_handling'
/Users/benasher/.rvm/gems/ruby-2.0.0-p648/gems/rake-10.4.2/lib/rake/application.rb:75:in `run'
/Users/benasher/.rvm/gems/ruby-2.0.0-p648/gems/rake-10.4.2/bin/rake:33:in `<top (required)>'
/Users/benasher/.rvm/gems/ruby-2.0.0-p648/bin/rake:23:in `load'
/Users/benasher/.rvm/gems/ruby-2.0.0-p648/bin/rake:23:in `<main>'
/Users/benasher/.rvm/gems/ruby-2.0.0-p648/bin/ruby_executable_hooks:15:in `eval'
/Users/benasher/.rvm/gems/ruby-2.0.0-p648/bin/ruby_executable_hooks:15:in `<main>'
Tasks: TOP => serve:drafts

I don't have time now, but I do plan on debugging this later.

benasher44 · 2016-09-12T16:03:30Z

@dantoml a few questions for you:

I feel like I'm missing some ways in which you can specify the Swift version in the podspec. I went based on your PR, but it seems like there might be pre-existing ways: spec.pod_target_xcconfig perhaps?.
I didn't mention the Dir.chdir issue, but that a lot of what was going on there went over my head. This is mostly because I haven't spent much time digesting those parts of Xcodeproj. Do you think this deserves mentioning (cc @segiddins)? This was quite a wrench thrown at us by Xcode 8.

orta · 2016-09-12T16:12:20Z

So, believe it or not 1.1 contains a pretty useful feature from me too, big enough to warrant a mention.

Error Handling Improvements

Now when CocoaPods receives unexpected errors it will highlight existing issues that might be related in the console. This makes it easier to find the answer to common issues. We do this by using gh_inspector which you may have seen inside Fastlane too.

benasher44 · 2016-09-12T16:26:41Z

Definitely! Sorry I missed It. I think I've just had Xcode 8 / extension tunnel vision the past few months. Will update the PR soon.

If anyone has any other big updates I missed, please chime in!

benasher44 · 2016-09-12T18:02:53Z

@orta added verbatim + a comma.

endocrimes · 2016-09-12T21:28:42Z

@benasher44

the pod target xcconfig will mean people can't integrate with the wrong version I think, which is nice for correctness. .swift-version is solely for linting/pushing.
I think it's probably worth mentioning, because we sank a lot of time into it. Honestly still not sure of the underlying cause, but it looks like DevToolsCore might be triggering a kernel bug?

benasher44 · 2016-09-14T13:36:21Z

pod target xcconfig won't do both?

For the DevToolsCore issue, I'm happy to include a section if you write it up 😀. It could just be a sentence or two in the Xcode 8 section

endocrimes · 2016-09-14T15:41:41Z

@benasher44 I don't think so, because it needs to be in the root project not just the pod targets?

orta · 2016-09-14T16:23:13Z

_drafts/1.1.0.markdown

+Xcode 8 is here! It brings support for iOS 10, macOS Sierra, new versions of Swift, and new challenges for CocoaPods. The first is the ability to support Swift 2.3 and 3.0 projects and communicate this in a podspec. In CocoaPods 1.1.0, setting the version of Swift that your pod uses is supported in following ways:
+
+* It defaults to Swift 2.3, if your pod uses Swift.
+* It uses setting from your `.swift-version` file if present (inspired by [swiftenv](https://github.com/kylef/swiftenv).


We should include a reference of what this looks like.

It uses setting from your .swift-version file if present (inspired by swiftenv.
This is a file that only contains the swift version as text: e.g. for Swift 3, you would have 3.0 in the file.

segiddins · 2016-09-14T17:22:11Z

_drafts/1.1.0.markdown

+author: nickname
+categories: cocoapods releases
+---
+TL;DR: _CocoaPods 1.1.0_ has been released, and it comes with improved support for extensions and frameworks, Xcode 8 support, and error handling improvements.


might want a  somewhere in here

benasher44 · 2016-09-15T12:57:37Z

@dantoml if the project is swift version unspecified, then I think all that matters is all of the swift pods being integrated need to have the compatible swift versions

benasher44 · 2016-09-15T13:01:58Z

Oh wait no that's clearly wrong because of CocoaPods/CocoaPods#5846. Hm. Maybe we should just be using the pod's build settings as a source of truth for setting the swift version for validation. Then, .swift-version file just becomes another way to set the pod's swift version setting like you could in pod_target_xcconfig. I think this might help some of the existing swift version confusion for pushing pods.

benasher44 · 2016-09-15T13:09:13Z

Also, I'm waiting on the resolution of CocoaPods/CocoaPods#5860. It appears I may have gotten it wrong for standalone messages applications. If that's that the case, then messages extensions are just like any other extension, and I should remove that section from the post.

benasher44 · 2016-09-15T13:10:47Z

The other possibility for this swift version issue is the swift version unspecified is different than the swift version setting is not set at all.

AliSoftware · 2016-09-20T14:48:40Z

It doesn't feel clear to me how pod authors are supposed to set the Swift version if they support multiple.

For example I have pods that support both 2.2, 2.3 and 3.0 in the same master branch. Should I create a .swift-version file containing 3.0 so that if the hosting project is itself 3.0 then CP will set the Swift version of the pod target to 3.0 and profit of the more modern API of my pod? Or should I not create that .swift-version file so that CP knows it's compatible with both 2.3 and 3.0? And in that case will it default to 2.3 even if the hosting user project is set to use 3.0?!

orta · 2016-09-20T14:50:36Z

It only sets the Swift version inside the linter, if your lib supports source-compatible 2.3 and 3.0 then 2.3 is fine. We keep no metadata around.

AliSoftware · 2016-09-20T14:58:38Z

_drafts/1.1.0.markdown

+
+### Xcode 8 and iOS 10
+
+Xcode 8 is here! It brings support for iOS 10, macOS Sierra, new versions of Swift, and new challenges for CocoaPods. The first is the ability to support Swift 2.3 and 3.0 projects and communicate this in a podspec. In CocoaPods 1.1.0, setting the version of Swift that your pod uses is supported in following ways:


[…] setting the Swift version your pod is gonna be verified and linted against can be done is the following ways:
…

Note that this only affect the linting. During integration of a pod, it's Swift version is set to the same version as the one used in the user's hosting project.

I'm going to rework this section soon. There are still a few Swift-related PRs to come I think. I'm going to wait for Swift support to stabilize before I update.

AliSoftware · 2016-09-20T15:00:10Z

@orta got it. Then might need some more explicit explanations fort that paragraph then (suggestion above)

orta · 2016-10-13T16:38:25Z

_drafts/1.1.0.markdown

+Xcode 8 is here! It brings support for iOS 10, macOS Sierra, new versions of Swift, and new challenges for CocoaPods. The first is the ability to support Swift 2.3 and 3.0 projects and communicate this in a podspec. In CocoaPods 1.1.0, setting the version of Swift that your pod uses is supported in following ways:
+
+* It defaults to Swift 2.3, if your pod uses Swift.
+* It uses setting from your `.swift-version` file if present (inspired by [swiftenv](https://github.com/kylef/swiftenv). This is a file that only contains the swift version as text: e.g. for Swift 3, you would have 3.0 in the file.


RC3 added --swift-version=VERSION - https://github.com/CocoaPods/CocoaPods/blob/master/CHANGELOG.md#110rc3-2016-10-11

benasher44 · 2016-10-15T18:45:52Z

In case anyone hits that backtrace again, it was because I hadn't added myself to _config.yml and configured the author properly (should have fully read the README).

- Swift version section - Updated descriptions - Cleaned up messages extension/app info

benasher44 · 2016-10-15T20:45:11Z

Alright, this is much closer to being ready now. I think the only thing left to add is something about CocoaPods/cocoadocs.org#473 if we do something there.

orta · 2016-10-17T10:46:19Z

_drafts/1.1.0.markdown

+3. We could add a `swift_version_range` option to indicate the range of Swift versions the pod supports, but this suffers from the same issues as option 2. There is no way to verify that a pod pushed today that claims to support up through Swift version 4 actually supports that version.
+
+In this release of CocoaPods, you lint your pod against the version of Swift you intend to support. When integrating pods, CocoaPods generates pod targets that use the Swift version set in your project. This allows pod authors the flexibility to support multiple incompatible swift versions if they wish by using `#if swift()` checks, while keeping the pod maintenance burden light across Swift 3 versions.
+


Might be nice to mention that we will actually be baking in the version of swift into the JSON podspecs, then people wanting to create tooling around the ecosystem can use those values?

For tool authors we're making it easy for others to work use the database of pods on trunk, by baking the version of Swift that was used to pass validation into the JSON file for a Podspec. This means you reliably build tooling that works against multiple versions of Swift.

Ideally we can make the "JSON file for a Podspec" a link to an example that shows it

I changed this around a bit, but it's now in there! Have a look at let me know if I didn't capture what you were getting at.

Is the plan to update this with a link once 1.1.0 is live, and we have an example from people pushing their specs?

Yeah, I can do that 👍

AliSoftware

I like that the blog post explains why the podspec doesn't contain a new attribute to specify the Swift version, as this has been a recurring question asked by a lot of people and the paragraph clarifies that perfectly.

Nice writing @benasher44 👌

endocrimes

LGTM, although I agree that it would be nice to also include a reference to the JSON Podspec

alloy · 2016-10-18T11:21:50Z

_drafts/1.1.0.markdown

+
+### About Supporting Multiple Swift Versions in the Podspec
+
+Supporting the Swift language version used by a pod as part of the podspec is tricky. There are a few different options we considered, but we ultimately decided not to add any new podspec dsl for this release. Here are some examples of options we considered for this release:


I’m missing details on why it’s so tricky to deal with Swift versions at all. E.g. Swift doesn’t use semantic versioning?

👍. Let me know if you think it's still unclear, and I'm happy to elaborate further!

alloy · 2016-10-18T11:22:41Z

I’m missing updates on all of the speed improvements done in this release, I believe there were great optimisations done, no?

orta · 2016-10-18T14:09:21Z

Speed improvements may have been caused by the previous 1.1.0 releases - not sure personally

endocrimes · 2016-10-18T14:12:57Z

@alloy @orta
Performance improvements were mostly in CocoaPods/CocoaPods#5927, CocoaPods/CocoaPods#5934, and CocoaPods/CocoaPods#5837.

@dnkoutso can probably elaborate more.

dnkoutso · 2016-10-18T15:27:04Z

The performance improvements were mostly done for larger projects during pod install by caching the result of various methods that are expensive because they perform a lot of file I/O.

I think the tl;dr is that pod install time is significantly improved, especially for large projects.

orta

🚢

1st draft of 1.1.0 blog post

3546204

Added error handling

f7e66b0

orta reviewed Sep 14, 2016
View reviewed changes

orta mentioned this pull request Sep 14, 2016

Trunk push fails with multiple errors with Swift 3 library CocoaPods/CocoaPods#5871

Closed

segiddins reviewed Sep 14, 2016
View reviewed changes

Feedback + messages fix

70735e0

AliSoftware reviewed Sep 20, 2016

View reviewed changes

orta reviewed Oct 13, 2016

View reviewed changes

Updated draft

c5b6b4d

- Swift version section - Updated descriptions - Cleaned up messages extension/app info

removed extra space in _config.yml

e9d1028

benasher44 mentioned this pull request Oct 17, 2016

Feature Suggestion: Language Version in Podspec CocoaPods/CocoaPods#5852

Closed

orta mentioned this pull request Oct 17, 2016

Include the swift version when sending to trunk CocoaPods/cocoapods-trunk#77

Merged

benasher44 changed the title ~~WIP blog post for 1.1.0 release~~ Blog post for 1.1.0 release Oct 17, 2016

orta reviewed Oct 18, 2016

View reviewed changes

AliSoftware approved these changes Oct 18, 2016

View reviewed changes

endocrimes approved these changes Oct 18, 2016

View reviewed changes

alloy reviewed Oct 18, 2016

View reviewed changes

benasher44 added 4 commits October 19, 2016 08:52

Add info about swift version in spec json

51692d4

mention no semver for swift

12efe66

added note about perf improvements

d5d0014

grammar/typo fixes

71409af

orta approved these changes Oct 19, 2016

View reviewed changes

endocrimes approved these changes Oct 19, 2016

View reviewed changes

moved 1.1.0 blog post out of drafts

025122a

endocrimes merged commit 3a1a3dd into CocoaPods:master Oct 19, 2016


		### Xcode 8 and iOS 10

		Xcode 8 is here! It brings support for iOS 10, macOS Sierra, new versions of Swift, and new challenges for CocoaPods. The first is the ability to support Swift 2.3 and 3.0 projects and communicate this in a podspec. In CocoaPods 1.1.0, setting the version of Swift that your pod uses is supported in following ways:

		3. We could add a `swift_version_range` option to indicate the range of Swift versions the pod supports, but this suffers from the same issues as option 2. There is no way to verify that a pod pushed today that claims to support up through Swift version 4 actually supports that version.

		In this release of CocoaPods, you lint your pod against the version of Swift you intend to support. When integrating pods, CocoaPods generates pod targets that use the Swift version set in your project. This allows pod authors the flexibility to support multiple incompatible swift versions if they wish by using `#if swift()` checks, while keeping the pod maintenance burden light across Swift 3 versions.


		### About Supporting Multiple Swift Versions in the Podspec

		Supporting the Swift language version used by a pod as part of the podspec is tricky. There are a few different options we considered, but we ultimately decided not to add any new podspec dsl for this release. Here are some examples of options we considered for this release:

Blog post for 1.1.0 release #135

Blog post for 1.1.0 release #135

Conversation

benasher44 commented Sep 12, 2016 • edited

benasher44 commented Sep 12, 2016

benasher44 commented Sep 12, 2016

orta commented Sep 12, 2016

Error Handling Improvements

benasher44 commented Sep 12, 2016

benasher44 commented Sep 12, 2016

endocrimes commented Sep 12, 2016

benasher44 commented Sep 14, 2016

endocrimes commented Sep 14, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

benasher44 commented Sep 15, 2016

benasher44 commented Sep 15, 2016 • edited

benasher44 commented Sep 15, 2016

benasher44 commented Sep 15, 2016

AliSoftware commented Sep 20, 2016

orta commented Sep 20, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

AliSoftware commented Sep 20, 2016

Choose a reason for hiding this comment

benasher44 commented Oct 15, 2016

benasher44 commented Oct 15, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

AliSoftware left a comment

Choose a reason for hiding this comment

endocrimes left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

alloy commented Oct 18, 2016

orta commented Oct 18, 2016

endocrimes commented Oct 18, 2016

dnkoutso commented Oct 18, 2016 • edited

orta left a comment

Choose a reason for hiding this comment

benasher44 commented Sep 12, 2016 •

edited

benasher44 commented Sep 15, 2016 •

edited

dnkoutso commented Oct 18, 2016 •

edited