Update About page for new changes

src/Packagist/WebBundle/Resources/views/About/about.html.twig

@@ -35,7 +35,6 @@ acme/email
     "description": "Logging for PHP 5.3",
     "keywords": ["log","logging"],
     "homepage": "http://github.com/Seldaek/monolog",
-    "version": "1.0.0",
     "license": "MIT",
     "authors": [
         {
@@ -49,26 +48,32 @@ acme/email
     }
 }
 </pre>
-Most of this information is obvious, keywords are tags, require are list of dependencies that your package has. This can of course be packages, not only a php version. You can use ext/foo to require php extensions (e.g. ext/apc). Note that most extensions don't expose version information, so unless you know for sure it does, it's safer to use <code>"ext-apc": "*"</code> to allow any version of it. Finally the type field is in this case indicating that this is a library. If you do plugins for frameworks etc, and if they integrate composer, they may have a custom package type for their plugins that you can use to install the package with their own installer. In the absence of custom type, you can omit it or use "library".</p>
+Most of this information is obvious, keywords are tags, require are list of dependencies that your package has. This can of course be packages, not only a php version. You can use ext-foo to require php extensions (e.g. ext-apc). Note that most extensions don't expose version information, so unless you know for sure it does, it's safer to use <code>"ext-apc": "*"</code> to allow any version of it. Finally the type field is in this case indicating that this is a library. If you do plugins for frameworks etc, and if they integrate composer, they may have a custom package type for their plugins that you can use to install the package with their own installer. In the absence of custom type, you can omit it or use "library".</p>
     <p>Known package types include: symfony-bundle</p>
     <p>Once you have this file committed in your repository root, you can <a href="{{ path('submit') }}">submit the package</a> to Packagist by entering the public repository URL.</p>
+
     <h1>Managing package versions</h1>
-    <p>New versions of your package are automatically fetched from tags you create in your repository. You should update the version field in the composer.json file before creating a tag. Tag/version names should match 'X.Y.Z', or 'vX.Y.Z', with an optional suffix for RC, beta, alpha or patch versions. Here are a few examples of valid tag names:
+    <p>New versions of your package are automatically fetched from tags you create in your VCS repository.</p>
+    <p>There are two ways to manage version numbering. The easiest is to just omit the version field from the composer.json file. If it is missing, the version name will be parsed from the tag and branch names. The other way which offers you a bit more flexibility is to define it yourself, but that means you should update the version field in the composer.json file before creating a tag, otherwise the tag will be considered broken and not imported. If you think you're likely to forget, you probably should use the first method.</p>
+    <p>Tag/version names should match 'X.Y.Z', or 'vX.Y.Z', with an optional suffix for RC, beta, alpha or patch versions. Here are a few examples of valid tag names:
 <pre>
 1.0.0
 v1.0.0
 1.10.5-RC1
 v4.4.4beta2
 v2.0.0-alpha
+v2.0.4-p1
 </pre>
-    In your master branch, or any other dev branch, you should change the composer.json version to the next future version that will be released from this branch (e.g. <code>1.1.0</code>), packagist will automatically suffix -dev to it until it is moved to a tag.</p>
+    With manual versioning, in your master branch, or any other dev branch, you should change the composer.json version to the next future version that will be released from this branch (e.g. <code>1.1.0</code>), packagist will automatically add a -dev suffix to it until it is moved to a tag.</p>
     <p>Note that dev branches should follow one of the following patterns to be recognized:
 <pre>
+master
+trunk
 1.0
 1.*
 v1.x
-1.x.x
-1.*.*
+1.1.x
+1.1.*
 </pre>
     Doing so will allow people to easily install pre-release versions of your code for testing or development purposes.</p>
 {% endblock %}