New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Beta quality drop of Objective C Support. #480
Conversation
thomasvl
commented
Jun 9, 2015
- Add more to the ObjC dir readme.
- Merge the ExtensionField and ExtensionDescriptor to reduce overhead.
- Fix an initialization race.
- Clean up the Xcode schemes.
- Remove the class/enum filter.
- Remove some forced inline that were bloating things without proof of performance wins.
- Rename some internal types to avoid conflicts with the well know types protos.
- Drop the use of ApplyFunctions to the compiler/optimizer can do what it wants.
- Better document some possible future improvements.
- Add missing support for parsing repeated primitive fields in packed or unpacked forms.
- Improve -hash.
- Add *Count for repeated and map<> fields to avoid auto create when checking for them being set.
- Add more to the ObjC dir readme. - Merge the ExtensionField and ExtensionDescriptor to reduce overhead. - Fix an initialization race. - Clean up the Xcode schemes. - Remove the class/enum filter. - Remove some forced inline that were bloating things without proof of performance wins. - Rename some internal types to avoid conflicts with the well know types protos. - Drop the use of ApplyFunctions to the compiler/optimizer can do what it wants. - Better document some possible future improvements. - Add missing support for parsing repeated primitive fields in packed or unpacked forms. - Improve -hash. - Add *Count for repeated and map<> fields to avoid auto create when checking for them being set.
This fixes issue #449 |
fyi: this has the support for parsing both packed and unpacked repeated fields. |
One question for objectivec runtime version number. Currently, it's 30000. How can it be used to differ 3.0.0-alpha-2 and 3.0.0-alpha-3? |
Right now I have specifically not been bumping it with each release and instead will only pump it after the initial release when we are making changes that break things. i.e. it won't directly track the main proto library version. Since there things that will depend on protos and have to be distributed in binary form, we will have to be very careful when we bump the version otherwise it will cause a ripple of incompatibility. |
btw - this seems to be the same sorta model as GOOGLE_PROTOBUF_VERSION, that doesn't have the alpha status in it. For now, I haven't given ObjC something like GOOGLE_PROTOBUF_MIN_PROTOC_VERSION or kMinHeaderVersionForLibrary for the runtime check. But all of them would need manual updating and not something that should be blindly changed without thinking through. |
Besides GOOGLE_PROTOBUF_VERSION, we have other places for version: 9839c0c |
There is also the podspec, https://cocoapods.org/?q=protobuf I believe @jcanizales set that to alpha3 when it was submitted, so we can push a final version when we drop alpha status. I don't know podspecs well, what appears to matter more is what is in that repository vs. what is in the actual sources here. |
Yes. Still, if everywhere else (per 9839c0c) "3.0.0-alpha-3" is currently used, let's by all means use that in the podspec too, to maintain sanity. |
Updated the version number for objective-c in #484 |
LGTM |
Beta quality drop of Objective C Support.