Open neonichu opened 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.
@CocoaPods/core would love to hear your opinions on this!
I would vote for option 1, because the number of patch releases of Xcode is minimal anyways, while it does make this safety foolproof.
@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.
@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.
@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
@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 :)
@alloy ah, right, that sounds :+1:
This might be a nice option to isolate things and just go to the fallback: https://github.com/emcien/iso_latte
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:
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 toyes
/no