- When configured "pull_request[type: opened] + push", workflow not getting triggered when there is a change in PR code/commits when the branch is from the parent's forked repo.
- Configured only pull_request event as any change can only go through PR. 
- pull_request event by default happens when opened, synchronize (means whenever there is change/commit, sync happens), and reopened. So this should be good enough for our use cases.

More details in [approach doc](https://docs.google.com/document/d/1YNYUAlEUXTi4UZG5gEFZGQ7oe7LxNKh7FYSg2qtIUvI/edit#heading=h.1c7qt5y1jb9)

Our objective is to (replicating the previous setup):
- Do Maven test of LPN tool modules common, data and java-build through a Maven profile.
- Also build and test run ant target “junit” that unit tests the java LPN  api jar after being built.
- Check whether LPN’s JS API/files are in ascii format/not. 
- More details are mentioned in [approach doc](https://docs.google.com/document/d/1YNYUAlEUXTi4UZG5gEFZGQ7oe7LxNKh7FYSg2qtIUvI/edit)

* [maven-release-plugin] prepare release v8.12.31

* [maven-release-plugin] prepare for next development iteration

* [maven-release-plugin] prepare release v8.12.30

* [maven-release-plugin] prepare for next development iteration

* [maven-release-plugin] prepare release v8.12.29

* [maven-release-plugin] prepare for next development iteration

Earlier, AYTF is adding additional CC when returning unformatted result - for cases where the input digits are dropped for formatting. Eg: MX case: "+5213314010666" => "+52 +5213314010666". b/183053929

Now we. are proactively ensuring that no formatting is applied, where a format is chosen that would otherwise have led to some digits being dropped.

Why the input digits are dropped:
- In MX, the mobile token (1) is no more used, so when it is present in input, the formatted result should not contain it.
- However when AYTF, we should not be removing the input digits on the fly.
- More details in cl/373115460 and b/183053929

* [maven-release-plugin] prepare release v8.12.28

* [maven-release-plugin] prepare for next development iteration

* [maven-release-plugin] prepare release v8.12.27

* [maven-release-plugin] prepare for next development iteration

* [maven-release-plugin] prepare release v8.12.26

* [maven-release-plugin] prepare for next development iteration

* [maven-release-plugin] prepare release v8.12.25

* [maven-release-plugin] prepare for next development iteration

* [maven-release-plugin] prepare release v8.12.24

* [maven-release-plugin] prepare for next development iteration

* Java and CPP port fixes.

* Js port update and added code changes notes.

* Updated text in code changes comments file.

* [maven-release-plugin] prepare release v8.12.23

* [maven-release-plugin] prepare for next development iteration

* [maven-release-plugin] prepare release v8.12.22

* [maven-release-plugin] prepare for next development iteration

* [maven-release-plugin] prepare release v8.12.21

* [maven-release-plugin] prepare for next development iteration

* [maven-release-plugin] prepare release v8.12.20

* [maven-release-plugin] prepare for next development iteration

* strictMissingRequire is not supported by recent Closure compiler

* JS: Explicitly require goog.proto2.Descriptor

[dialr](https://github.com/socialresearchcentre/dialr/) is an R wrapper around the libphonenumber Java library (not a port as such)

* [maven-release-plugin] prepare release v8.12.19

* [maven-release-plugin] prepare for next development iteration

* Update M2M FAQ

This is with regards to setting up the expectations like "We cannot commit on any deadlines" though we are sure of the approach after weighing the ramifications. Make it clear that M2M use case are diverse and its demand for new Util API.