search

CocoaPods / Xcodeproj

Create and modify Xcode projects from Ruby.
http://rubygems.org/gems/xcodeproj
MIT License
2.34k stars 452 forks source link

Improve safety of Xcode private framework integration #276

Open neonichu opened 9 years ago

neonichu commented 9 years ago

Following up the discussion from #275

Since we saw with Xcode 7 beta 2 that our use of Xcode's private frameworks is more prone to breakage than anticipated, we should make sure that Xcodeproj continues to work even when that integration breaks.

I like @alloy's proposal a lot that we explicitly define supported versions, the question is how strict should that be:

  1. Use compatibility UUIDs Xcode provides: very reliable, as they change on any potential breakage, but that also means more frequent Xcodeproj releases would be required, one for every beta version as well as any new major/minor/patch version of Xcode
  2. Use major.minor: we assume that it is unlikely for Xcode to break in patch releases or between betas, as the functionality we use is fairly minimal and shouldn't frequently change, but there's still a slight chance of breakage. Major advantage would be only having to update the compatibility list every other month.

In addition to that, we should have an environment variable XCODEPROJ_NATIVE_SERIALIZATION which allows explicit opt-in/-out by users if it is set to yes/no

neonichu commented 9 years ago

I'm leaning towards option 2 for the compatibility, as users would still have the option of opting out via env variable in case the unlikely breakage occurs, while not putting too much burden on us to constantly release new versions of Xcodeproj just to update the compatibility information.

neonichu commented 9 years ago

@CocoaPods/core would love to hear your opinions on this!

alloy commented 9 years ago

I would vote for option 1, because the number of patch releases of Xcode is minimal anyways, while it does make this safety foolproof.

neonichu commented 9 years ago

@alloy keep in mind that every beta also gets a new UUID, though, so for a while that means a new release every two weeks - however one could argue that those installing betas should be equipped to set the environment variable.

alloy commented 9 years ago

@neonichu Oh yeah, I wouldn’t do it for each beta, but option 2 is ignoring those too so there’s not any difference there.

neonichu commented 9 years ago

@alloy ah, so you're saying we use major.minor.bugfix as the reference? Because the UUIDs simply do change between each beta and there's no easy way to identify them apart from that

alloy commented 9 years ago

@neonichu I think cutting a Xcodeproj version for each new major.minor.bugfix would be good enough, except you’d recognise them by UUID. So betas won’t be recognised and would need the env variable.

You can still add the beta UUIDs to master, that way people on the edge will have a working version and whenever you release a CP version that includes these UUIDs people can still use the betas, you just wouldn’t cut a release just for them.

I also now realise that this means by comment about option 2 ignoring betas too was wrong :)

neonichu commented 9 years ago

@alloy ah, right, that sounds :+1:

neonichu commented 9 years ago

This might be a nice option to isolate things and just go to the fallback: https://github.com/emcien/iso_latte