v8.3.0

Hi all,

Please find the new JARs on the maven site here.

The new release contains metadata changes and some code changes. Upgrading to the latest release is always encouraged since phone number information changes often!

New functionality in this release:

• Two new ValidationResult enum values have been added, which in a future release will be returned by isPossibleNumberWithReason. Please see this thread on the mailing list for a thorough explanation of changes you might need to make if you use this method.
• isNumberMatch has been improved to better compare numbers which weren't created purely by calling "parse" as recommended.
• C++ only changes: the maximum allowed length for a national significant number was increased to 17 for parity with Java, and the method ExactlySameAs to compare two phone number protos was fixed to also consider the number_of_leading_zeros field.

Full details in the release notes.

Note if you take advantage of the new enums by changing your code, it will not necessarily be trivially easy to roll back to a previous version.

Thanks to all those who contributed by providing issue reports!

Want to be notified of future releases? Join the discussion group!

v8.2.0

Hi all,

Please find the new JARs on the maven site here.

The new release contains metadata changes
and some code changes. Upgrading to the latest release is always encouraged
since phone number information changes often!

New functionality in this release:

• Made normalizeDiallableCharsOnly() API in PhoneNumberUtil (Java) public. This method is already public in the C++ implementation. It has also now been added to the Javascript implementation.

Full details in the release notes.

Note if you take advantage of this new functionality by changing your code,
it will not necessarily be trivially easy to roll back to a previous
version.

Thanks to all those who contributed by providing issue reports!

Want to be notified of future releases? Join the discussion group!

v8.1.0

Hi all,

Please find the new JARs on the maven site here.

The new release contains metadata changes and some code changes. Upgrading to the latest release is always encouraged since phone number information changes often!

New functionality in this release:

• New API in ShortNumberUtil to calculate whether a short number is carrier specific or not for a particular region (isCarrierSpecificForRegion). This API should be preferred over the old isCarrierSpecific API, which did not take region into account.

We consider a number to be carrier-specific if it connects to a different endpoint or does not connect at all, depending on the caller's carrier. With the new API a short number that is valid in multiple regions that share a country calling code (e.g. Bermuda and the United States, both of which use the country calling code 1) will now return whether it is carrier-specific or not for the particular region passed in - since it may, for example, be carrier-specific in Bermuda, but not in the United States.

Full details in the release notes.

Note if you take advantage of this new functionality by changing your code, it will not necessarily be trivially easy to roll back to a previous version.

Thanks to all those who contributed by providing issue reports!

Want to be notified of future releases? Join the discussion group!

v8.0.1

Greetings,

Please find the new JARs on the maven site here.

The new release contains mostly metadata changes.
Thanks to all those who contributed by providing issue reports!
See detailed release notes.

For those who depend on libphonenumber releases from GitHub tags:
We published and deleted tags named v8.0.1 several times over 11th and 12th January while diagnosing a Maven issue that had blocked our release.

What you should do:
First, determine the impact on your project. The libphonenumber library metadata and code are identical across the different v8.0.1 publications. This probably doesn't affect you if either of the following applies:

• You didn't pick up the tag on 11th or 12th January.
• You don't copy or use the pom.xml files in any way and you don't care about the timestamp, exact size, and other build-time details of the tag's contents.

If you are affected or have any doubts, please pick up the tag that we published on 13th January, which is stable; and alert your clients and porters about any subsequent action they should take.

Please refer to the discussion group announcement for more details.

Want to be notified of future releases? Join the discussion group!

v8.0.0

Hi all,

Please find the new JARs on the maven site here.

Warning: this release may break your code unless you update your code at the same time, as it has the following breaking changes:

• Deleted deprecated methods in ShortNumberInfo that work on strings, instead of phone number objects. These have been marked deprecated for months. Any users of these methods should call PhoneNumberUtil.parse first to create a PhoneNumber object, and pass this in.
• Support semicolon as extension character while parsing phone numbers. This is not applicable when you are trying to find the phone numbers.
• Updated JavaScript to throw an error rather than a string. As a result, users doing custom behavior depending on the value of the error must now compare to the value of e.message.

Special note:

• This is our last release of the year. We'll aim to resume releases in the second week of January.

Full details in the release notes.

Thanks to all those who contributed by providing issue reports!

Want to be notified of future breaking releases? Join the discussion group!

v7.7.5

Hi all,

Please find the new JARs on the maven site here.

The new release contains mostly metadata changes.
Thanks to all those who contributed by providing issue reports!
See detailed release notes.

Want to be notified of future releases? Join the discussion group!

Thanks & Regards,
Aravind

v7.7.4

Hi all,

Please find the new JARs on the maven site here.

The new release contains mostly metadata changes

Code changes in this release:

• Using new possibleLengthInfo to decide whether a short number is the right
  length or not. This could result in more specific results; whereas before, a
  number from length 3 to length 6 may have been deemed possible, now we may
  exclude a number of length 5.
• Add hash (#) as a diallable character. Numbers with # in them will no longer
  have formatting applied in formatInOriginalFormat, and
  normalizeDiallableCharsOnly now retains the # symbol.
• getExampleNumberForNonGeoEntity has been changed to look at the specific
  number types, not just the generalDesc, for the example numbers; this is a
  necessary change due to changes in the metadata structure, see details for porters below.

Full details in the release notes.

Porting or packaging libphonenumber?
There are a series of changes affecting people who port or package libphonenumber. Changes range from how the metadata is organized internally to how releases are tagged.
For full details, see our separate announcement for port maintainers.

Thanks to all those who contributed by providing issue reports!

Want to be notified of future releases? Join the discussion group!

libphonenumber-7.7.2

Hi all,

Please find the new JARs on the maven site here.

Warning: this release may break your code unless you update your code at the same time, as it has the following breaking changes:

• Calls to formatNationalNumberWithPreferredCarrierCode, where parseAndKeepRawInput was used to provide the phone number and no carrier code was found, will now use the fallback carrier code. Before we erroneously used an empty string as a carrier code.
• Calls to formatNumberForMobileDialing for Brazilian numbers previously produced output for any number, regardless of whether a carrier code was found or not, so long as the number had been obtained with parseAndKeepRawInput. Now if no carrier code was found, no output will be produced, because we can't guarantee the number is diallable. If you want to get output regardless, you will need to explicitly set a carrier code for Brazilian numbers if none was present.

You may also need to update any tests that rely on the exact result of parsing a number using parseAndKeepRawInput, since the preferred_domestic_carrier_code won't be set where it was previously empty.

Full details in the release notes, along with information on what metadata has changed.

In light of the fact that this may require changes from clients using these methods to achieve the same behaviour as previous releases, we should have tagged this release as v8.0.0; apologies for this oversight. We hope it won't cause too much inconvenience.

Thanks to all those who contributed by providing issue reports!

Want to be notified of future breaking releases? Join the discussion group!

libphonenumber-7.7.0

Greetings,

Please find the new JARs on the maven site here.

The new release contains only code changes and no metadata changes.

New functionality in this release:

• Removed the dependency on protobuf-javanano from the Java library. This resulted in a minor reduction in the size of the libphonenumber jar. If you added a dependency on protobuf-javanano due to libphonenumber-7.6.0 it is now safe to remove this dependency.

More details in the release notes.

Note if you take advantage of this new functionality by changing your code, it will not necessarily be trivially easy to roll back to a previous version, since you will have to re-add the dependency.

Cheers,
Keghani, on behalf of the libphonenumber team

Want to be notified of future releases? Join the discussion group!

libphonenumber-7.6.0

Greetings,

Please find the new JARs on the maven site here.

The new release contains metadata changes and some code changes. Upgrading to the latest release is always encouraged since phone number information changes often!

New functionality in this release:

• Use protobuf-javanano runtime dependencies from the Maven Repository in our build. Previously we were packaging these dependencies directly in our jar, which was bad practice and a bad experience for clients*.
  • We hope this is good news for many of you. If this version has unintended consequences please let us know ASAP by reporting an issue on GitHub.
  • For more technical details on what changed, see PR #1282.
• Made isNumberGeographical public, and changed the geocoder to use this when checking whether to give a detailed answer or country-level only.

Full details in the release notes.

Warning: If you don't compile your project with protobuf-javanano dependencies, this release will break your code unless you update your code at the same time. You need to ensure that you have protobuf-javanano dependencies in your build. For example, if you compile with Maven, add the following under dependencies:

<dependency>
  <groupId>com.google.protobuf.nano</groupId>
  <artifactId>protobuf-javanano</artifactId>
  <version>3.0.0-alpha-7</version>
</dependency>

If you have tips on adding this dependency for other build systems, please chime in on the release announcement thread!

Moreover, if you already had protobuf-javanano dependencies in your own project, be aware that we stopped renaming Java imports for com.google.protobuf.nano to com.google.i18n.phonenumbers.repackaged.com.google.protobuf.nano in our files.
Repackaging (PR #1099) was a temporary workaround until we removed the dependencies from the jars.

Finally, if you take advantage of the new functionality (isNumberGeographical) by changing your code, it will not necessarily be trivially easy to roll back to a previous version.

Thanks to all those who contributed by providing issue reports!

Cheers,
Keghani, on behalf of the libphonenumber team

* See #913, #956, #1070

Want to be notified of future breaking releases? Join the discussion group!