Update README.md / VERSIONS.md

Author: jingming

README.md

@@ -28,12 +28,11 @@ String authToken = "XXXXXXXX"; // Your Auth Token from www.twilio.com/user/accou
 
 Twilio.init(accountSid, authToken);
 
-Message message = Message.create(
-    ACCOUNT_SID,
-    new PhoneNumber("+15558881234"),
-    new PhoneNumber("+15559994321"),
-    "Hello world!"
-).execute();
+Message message = Message.creator(
+    new PhoneNumber("+15558881234"),  // To number
+    new PhoneNumber("+15559994321"),  // From number
+    "Hello world!"                    // SMS body
+).create();
 
 System.out.println(message.getSid());
 ```
@@ -45,14 +44,13 @@ String authToken = "XXXXXXXX"; // Your Auth Token from www.twilio.com/user/accou
 
 Twilio.init(accountSid, authToken);
 
-Call call = Call.create(
-    ACCOUNT_SID,
-    new PhoneNumber("+15558881234"),
-    new PhoneNumber("+15559994321"),
+Call call = Call.creator(
+    new PhoneNumber("+15558881234"),  // To number
+    new PhoneNumber("+15559994321"),  // From number
 
     // Read TwiML at this URL when a call connects (hold music)
     new URI("http://twimlets.com/holdmusic?Bucket=com.twilio.music.ambient")
-).execute();
+).create();
 
 System.out.println(call.getSid());
 ```

VERSIONS.md

@@ -1,26 +1,31 @@
 # Versioning Strategy
 
-`twilio-java` uses [Semantic Versioning][semver] for all changes to the helper 
-library.  It is strongly encouraged that you pin at least the major version to 
-avoid pulling in breaking changes.
+`twilio-java` uses a modified version of [Semantic Versioning][semver] for all 
+changes to the helper library.  It is strongly encouraged that you pin at least 
+the major version and potentially the minor version to avoid pulling in breaking 
+changes.
 
 Semantic Versions take the form of `MAJOR`.`MINOR`.`PATCH`
 
 When bugs are fixed in the library in a backwards compatible way, the `PATCH` 
-level will be incremented by one.  `PATCH` changes should _not_ break your code 
-and are generally safe to upgrade to.
-
-When new features are added to the library in a backwards compatible way, the 
-`MINOR` level will be incremented by one and the `PATCH` level will be reset to
-zero.  `MINOR` changes are should _not_ break your code and are generally safe
-to upgrade to.  After a `MINOR` change you may wish to review the helper library
-for new features and functionality.
-
-When a bug or feature requires a breaking change, the `MAJOR` level will be 
-incremented by one and the `MINOR` and `PATCH` levels will reset to zero.  These
-changes can break your code.  Twilio understands that this can be very 
-disruptive, we will only introduce breaking changes when absolutely necessary. 
-Breaking changes will be communicated in advance with `Release Candidates` and a
+level will be incremented by one.  When new features are added to the library 
+in a backwards compatible way, the `PATCH` level will be incremented by one.
+`PATCH` changes should _not_ break your code and are generally safe for upgrade.
+
+When a new large feature set comes online or a small breaking change is 
+introduced, the `MINOR` version will be incremented by one and the `PATCH` 
+version reset to zero. `MINOR` changes _may_ require some amount of manual code
+change for upgrade. These backwards-incompatible changes will generally be limited 
+to a small number of function signature changes.
+
+The `MAJOR` version is used to indicate the family of technology represented by 
+the helper library.  It increased from `6.x.x` to `7.x.x` when Twilio moved to 
+auto generation of helper libraries.  Breaking changes that requires extensive 
+reworking of code (like the `6.x.x` to `7.x.x` upgrade) will case the `MAJOR` 
+version to be incremented by one, the `MINOR` and `PATCH` versions will be reset 
+to zero.  Twilio understands that this can be very disruptive, we will only 
+introduce this type of breaking change when absolutely necessary. New `MAJOR` 
+versions will be communicated in advance with `Release Candidates` and a 
 schedule.
 
 ## Supported Versions
@@ -35,25 +40,25 @@ features.
 Twilio frequently rolls out new features in public and private beta periods.
 Twilio strives to ship early and often and bake customer feedback back into our 
 products.  To support that mission, the `twilio-java` helper library has an 
-`Edge` version based of the `edge` branch.  This version is identified with an
-`edge` metadata tag on the version number.
+`Edge` version based of the `alpha` branch.  This version is identified with an
+`alpha` metadata tag on the version number.
 
 The way the `Edge` artifact is created is by playing the `Edge` features on top
 of our stable artifact.  The `Edge` artifact will always have the same version 
-number as the stable artifact it was created from, but with an `edge` suffix.
+number as the stable artifact it was created from, but with an `alpha` suffix.
 
-For example, `5.0.1-edge1` is the `5.0.1` branch with `Edge` features included.
+For example, `7.1.0-alpha-1` is the `7.1.0` branch with `Edge` features included.
 If there is a change to one of the `Edge` features we may regenerate the `Edge`
-artifact and release a new `5.0.1-edge2`, new `Edge` artifacts simply increment
-the number after the `edge` suffix.  All `Edge` features are considered 
+artifact and release a new `7.1.0-alpha-2`, new `Edge` artifacts simply increment
+the number after the `alpha` suffix.  All `Edge` features are considered 
 unstable and a backwards incompatible change in an `Edge` feature will not cause
-any version change so you should take care when upgrading from one `edge` 
+any version change so you should take care when upgrading from one `alpha` 
 version to another.  
 
 Once an `Edge` feature has matured it will be considered `Mainline` and included
 in the stable artifact, with a `MAJOR` or `MINOR` version bump.
 
 To use an `Edge` artifact in your JAVA project you will have to make sure that 
-you pin the artifact with `edge` stability in your `pom.xml`.
+you pin the artifact with `alpha` stability in your `pom.xml`.
 
 [semver]: http://semver.org/