This excludes editing the proto file itself, or the auto-generated or hand-crafted fields that are derived from it.

Metadata changes:
-- Drops the "-1" that was erroneously included in possible lengths before (didn't break anything, but was wrong) - it was a possibleLength of a sub-component so got added to the generalDesc possibleLengths
-- possibleNumberPattern no longer inherited: we don't use this anyway, we will do another CL soon to stop including it at all in the generated metadata
-- exampleNumber is no longer set on fixed-line and mobile elements from the generalDesc

XML file changes:
-- Stopped specifying "NA" and "-1" specifically for fixed-line and mobile blocks; now they are treated as every other type of phone number: if missing, don't fill them in from generalDesc, but leave them missing.

Code changes:
-- Stop using the exampleNumber on generalDesc for non-geo entities, but look at their phonenumber descs - the exampleNumber won't be stored on the generalDesc anymore. This affects porters if they either copied our build logic or used our built metadata in some way; they should update this method in their port too.

Using new possible length information to calculate whether a short
number is the right length or not. This made us realise that the data
was missing for MY; this was added.

* Porting code to use the new possible length information for calculating
whether a phone number is possible, too short etc.

-- changing to use ULL in test numbers so this compiles on all platforms (fixes issue #1334)
-- updating a couple of test-cases/comments to bring inline with Java

Sep 19, 2016: libphonenumber-7.7.0

Code changes:

Removed the dependency on protobuf (protobuf-javanano) from the Java library, resurrecting java/libphonenumber/src/com/google/i18n/phonenumbers/Phonemetadata.java which was present until libphonenumber-7.1.1.

Does not affect the C++ or JavaScript libraries.

We remove the dependency on protobuf (protobuf-javanano) from the Java library, resurrecting java/libphonenumber/src/com/google/i18n/phonenumbers/Phonemetadata.java which was present until libphonenumber-7.1.1.

Does not affect the C++ or JavaScript libraries.

Code changes:

* Phonemetadata.java has two more fields to represent possible lengths of phone numbers. Changed BuildMetadataFromXml (and the resultant jar) to alter the way that metadata about possible-lengths information is consumed when constructing metadata to populate these. Discussion list email: https://groups.google.com/forum/#!topic/libphonenumber-discuss/75TOpTFVi08

Metadata changes:

* Updated phone metadata for region code(s): AG, AM, AX, BY, CD, FI, IN, KR, MA, NA, NL, PK, SY
* Updated short number metadata for region code(s): BR, GB, NL, NZ
* New geocoding data for country calling code(s): 82 (pl, pt, ro, ru, sl, sr, uk, vi)
* Updated carrier data for country calling code(s): 27 (en), 91 (en), 243 (en), 963 (en)

https://groups.google.com/forum/#!topic/libphonenumber-discuss/75TOpTFVi08

* Initial code changes to support the new possibleLengths infrastructure
when building metadata. Includes setting these in the main metadata
file and changing the code to populate them in the PhoneMetadata proto
at build time. Updating tests for Java.

* Updating comment about the possible_lengths_local_only field.

* Adding the generated jars that build files containing the new possible
lengths fields.

* Rebuilding short-number metadata with the new proto field. Not doing
this at release time so we can see what changes in the metadata are due
to metadata fixes, rather than this possibleLengths field.

* Regeneration of phone number metadata with the new possible length
information filled in.

Includes some possible length changes for KR and BY, and a validation
fix for NA where a digit was missing.

* Updating the test proto metadata files with the new possible length
information.

* Added notes about the code changes.

* Regenerating C++ metadata with new possibleLength info and updating unit
test to check this works.

Aug 24, 2016: libphonenumber-7.6.0
Code changes:

Refactored metadata loading and closed all streams after loading.
Made isNumberGeographical public, and changed the geocoder to use this when checking whether to give a detailed answer or country-level only.
Build changes:

Use protobuf-javanano 3.0.0-alpha-7 from Maven Central.
Metadata changes:

Updated phone metadata for region code(s): EH, ET, JM, MA, SK, SN, SY, ZM
Updated short number metadata for region code(s): ZA
Updated geocoding data for country calling code(s): 212 (en)
New carrier data for country calling code(s): 86 (zh, zh_Hant), 852 (zh, zh_Hant), 963 (en)
Updated carrier data for country calling code(s): 86 (en), 212 (en), 251 (en), 421 (en)
Deleted unsupported SingleFilePhoneNumberMetadataProto

Making function IsNumberGeographical public. This function operates on
the type of number and the country it belongs to only, so may have some
false positives.

Using this in the geocoder so that geocoding now limited to numbers that
we consider geographical, based on their type and country, rather than
just based on their type. The C++ geocoder did not previously check the
number type/country at all.

Indonesian and Chinese mobile numbers have now been added to the list of
possibly-geographical numbers.

* Metadata updates for release 7.4.4

* Update release_notes.txt

A future change to RE2 will replace the VariadicFunction2 objects with variadic
templates, which would break the code in libphonenumber as it currently stands.

* Metadata updates for release 7.3.2

* Unit tests for Canada Short number updates

This is similar to the fix of #822.

Also update README to cover Mac installation.

This rolls back the cmake minimum version bump in #975 since it was
backwards-incompatible, and the following #984. Not expected to cause
any new user-facing regressions, but expected to solve any that were
introduced with #975.

* New useful getExampleNumber methods (for testing) - one for invalid
  numbers and one for getting a number of a particular type without
  specifying a country.

alternate formats to be included to be found. This means that if the
user doesn't have this option set to true, the tests won't be run (they
would otherwise fail).

the end of the range as well, causing re2 to fail (and some test
failures with newer versions of ICU apparently in some configurations)

This is necessary to guarantee that parallel builds will succeed, all
top-level targets that include geocoding_data.cc in their builds need
explicitly listed dependencies on generate_geocoding_data to ensure that
generation of the file has finished before it is being used.

- using reserved keyword "test" in the custom target
 - bumping up the makefile version to avoid issues with policy changes
   relating to rpath

This fixes #822.