shssoichiro · March 18, 2016 03:29 · Mar 18, 2016 · Mar 18, 2016 · Mar 18, 2016
diff --git a/VERVER.md b/VERVER.md
@@ -47,7 +47,8 @@ Write a blog post.
 
 ### Who else uses VerVer?
 
-| Company   | Product                |
-|-----------|------------------------|
-| Microsoft | Windows                |
-| IntelliJ  | All IDE products       |
+| Company   | Product                 |
+|-----------|-------------------------|
+| Microsoft | Windows                 |
+| IntelliJ  | All IDE products        |
+| Adobe     | Creative Suite products |
diff --git a/VERVER.md b/VERVER.md
@@ -21,7 +21,7 @@ As a solution to this problem, I propose Version Versioning as a solution. Devel
 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119](http://tools.ietf.org/html/rfc2119).
 
 1. Each release MUST have a version number.
-2. A version number MAY or MAY NOT be a number.
+2. A version number MAY be a number.
 3. A normal version number MAY follow a predefined format, such as SemVer, or it MAY be an arbitrary, developer-defined format, such as YYYY.MM or an incrementing build number.
 4. Consecutive releases following the same version scheme SHOULD follow the rules defined for that version scheme.
 5. Non-consecutive releases following the same version scheme MAY follow the rules defined for that version scheme.

diff --git a/VERVER.md b/VERVER.md
@@ -0,0 +1,53 @@
+# Version Versioning v2016.03
+
+## Summary
+
+The version format of your project changes arbitrarily.
+
+## Introduction
+
+As you manage a software product, you will have many choices on how to manage the versions of it. Most versioning systems have the following problems:
+
+- Logical progression of versioning
+- Strict compliance is difficult
+- Choosing a version scheme is hard
+
+As your product evolves, you will find that your existing version scheme is no longer suitable for your product base and that you must change it. However, you cannot change the versioning scheme of your product without breaking expectations of code compatibility.
+
+As a solution to this problem, I propose Version Versioning as a solution. Developers will initially benefit from saving valuable time having to ensure that their version scheme is constant from one version to the next. You can switch between version schemes at will based on whatever fits your product best at a given moment.
+
+## Version Versioning Specification (VerVer)
+
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119](http://tools.ietf.org/html/rfc2119).
+
+1. Each release MUST have a version number.
+2. A version number MAY or MAY NOT be a number.
+3. A normal version number MAY follow a predefined format, such as SemVer, or it MAY be an arbitrary, developer-defined format, such as YYYY.MM or an incrementing build number.
+4. Consecutive releases following the same version scheme SHOULD follow the rules defined for that version scheme.
+5. Non-consecutive releases following the same version scheme MAY follow the rules defined for that version scheme.
+6. The version scheme MAY change between any two releases.
+
+## FAQ
+
+### How do my users know when a version scheme has changed?
+
+Write a blog post.
+
+### How do my users know what the latest version is?
+
+Write a blog post, or include an automatic updater with your product.
+
+### How do my users know when a backwards compatibility break has occurred?
+
+Write a blog post.
+
+### How should I handle deprecating functionality?
+
+Write a blog post.
+
+### Who else uses VerVer?
+
+| Company   | Product                |
+|-----------|------------------------|
+| Microsoft | Windows                |
+| IntelliJ  | All IDE products       |
No results found