In Python 2.6 the positional argument specifiers are apparently required
to be explicitly specified:
http://stackoverflow.com/questions/10054122/valueerror-zero-length-field-name-in-format-python

This includes all internal changes from around May 20 to now.

There was a twist code path (that some times showed up due to what happened to
be in memory in failure cases), that would cast a bogus wire type into the
enum, and then fall through switch statements.

Resolve this by validating all wire types when parsing tags and throwing the
error at that point so it can't enter the system.

As added safety, stick in a few asserts for apis that get passed tags to ensure
they also are only seeing valid data.

Bonus: Tweak the parsing loop to skip some work when we get the end marker
(zero tag) instead of still looping through all the fields.

Fix GPBGetMessage{Repeated,Map}Field()

* Adding condition compiler symbol to support .NET 3.5

- Correct impl by using helpers the message wiring does.
- Add unittests.

Fixes https://github.com/google/protobuf/issues/1716

Fix Objective-C generator option readme typo

Looks like this was changed during #1683, but missed in the README :)

Get value from text format name in GPBEnumDescriptor

Updates to package.json: rev version, add WKT, and recateogrize dependencies

Expose JsonFormatter.WriteValue.

This isn't useful to most users, but can be handy in advanced use cases,
as requested in #1465.

The runtime doesn't depend on anything, so these
packages should always have been in devDependencies.

Remove ordering guarantees in the MapField documentation

Note: Breaking API change on the Dictionary classes.

The numeric value classes were using "Value" in the naming, but this silently
collided with the KVC category on NSObject; meaning KVC code could break up a
keypath and call these selectors with the wrong types leading to crashes (even
though the code all would compile cleanly).

- Rename the methods to use the "type" instead of literal "Value".
- Update all the impls and tests.
- Enable the warning that will catch issues like this in the future.

Fixes https://github.com/google/protobuf/issues/1616

This doesn't currently change the ordering in the implementation, but allows us to do so in the future.
We also need to change
https://developers.google.com/protocol-buffers/docs/reference/csharp-generated#singular
which states "Finally, unlike Dictionary<TKey, TValue>, MapField<TKey, TValue> preserves insertion order of entries."
(We can just remove that sentence, I think.)

Adds destination flag to xcodebuild to avoid possible flake errors

CMake Fix up prerelease version handling

JS: import well-known types from google-protobuf package.

- Better docs in the generator for the different options that can be passed
  during an invoke of protoc.
- Add named_framework_to_proto_path_mappings_path to pass the path to a file
  containing mappings of frameworks for different proto files.
- Update the generation to use the mapping to change the #import directives
  it creates.

Note: the changes in helpers is mostly moving code within the fine, and then
a small change to expose the parsing so a passed on class can consume the line.

Fixes https://github.com/google/protobuf/issues/1457

Workaround for gcc-4.4 incompatibility

constructor, and instead create an _internal_only getter
that gets the needed information. This is a workaround for
a deficiency in gcc-4.4 that does not properly support
templated friend classes.

Cleanup protobuf-module.cmake.in

CMake package requirements

Add support for generation sources into a framework.

- Add a protoc objc option (generate_for_named_framework) to set the name of
  the framework all generated sources will be in.
- Tweak some comments/naming to make it clear what is the Protobuf framework
  vs. the framework for generated code.
- Update the objc README to document the new generation option to protoc.

This is working towards https://github.com/google/protobuf/issues/1457.

Also hotwires updating ruby as CocoaPods was crashing within a support library.

Fixes #1619 

proper codeblock in README