Author: buildbot
Date: Sun Dec 14 18:57:24 2014
New Revision: 932725
Log:
Staging update by buildbot for accumulo
Modified:
websites/staging/accumulo/trunk/content/ (props changed)
websites/staging/accumulo/trunk/content/versioning.html
Propchange: websites/staging/accumulo/trunk/content/
------------------------------------------------------------------------------
--- cms:source-revision (original)
+++ cms:source-revision Sun Dec 14 18:57:24 2014
@@ -1 +1 @@
-1645479
+1645493
Modified: websites/staging/accumulo/trunk/content/versioning.html
==============================================================================
--- websites/staging/accumulo/trunk/content/versioning.html (original)
+++ websites/staging/accumulo/trunk/content/versioning.html Sun Dec 14 18:57:24
2014
@@ -34,7 +34,7 @@
<script src="/js/dataTables.bootstrap.js"></script>
<link href="/css/accumulo.css" rel="stylesheet" type="text/css">
<link
href="//netdna.bootstrapcdn.com/font-awesome/4.0.3/css/font-awesome.css"
rel="stylesheet">
- <title>Apache Accumulo Git WIP</title>
+ <title>Apache Accumulo Versioning</title>
<script>
(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
@@ -190,429 +190,75 @@ Latest 1.5 release: <strong>1.5.2</stron
<div id="content">
- <h1 class="title">Apache Accumulo Git WIP</h1>
+ <h1 class="title">Apache Accumulo Versioning</h1>
- <p><a href="http://git-scm.com";>Git</a> is an open source, distributed
version control system
-which has become very popular in large, complicated software projects due to
-its efficient handling of multiple, simultaneously and independently developed
-branches of source code.\</p>
-<h2 id="workflow-background">Workflow Background</h2>
-<p>Likely the most contested subject matter regarding switching an active team
-from one SCM tool to another is a shift in the development paradigm.</p>
-<p>Some background, the common case, as is present with this team, is that
-developers coming from a Subversion history are very light on merging being a
-critical consideration on how to perform development. Because merging in
-Subversion is typically of no consequence to the complete view of history, not
-to mention that Subversion allows "merging" of specific revisions instead of
-sub-trees. As such, a transition to Git typically requires a shift in mindset
-in which a fix is not arbitrarily applied to trunk (whatever the main
-development is called), but the fix should be applied to the earliest, non
-end-of-life (EOL) version of the application.</p>
-<p>For example, say there is a hypothetical application which has just released
-version-3 of their software and have shifted their development to a version-4
-WIP. Version-2 is still supported, while version-1 was just EOL'ed. Each
-version still has a branch. A bug was just found which affects all released
-versions of this application. In Subversion, considering the history in the
-repository, it is of no consequence where the change is initially applied,
-because a Subversion merge is capable of merging it to any other version.
-History does not suffer because Subversion doesn't have the capacities to
-accurately track the change across multiple branches. In Git, to maintain a
-non-duplicative history, it is imperative that the developer choose the correct
-branch to fix the bug in. In this case, since version-1 is EOL'ed, version-2,
-version-3 and the WIP version-4 are candidates. The earliest version is
-obviously version-2; so, the change should be applied in version-2, merged to
-version-3 and then the version-4 WIP.</p>
-<p>The importance of this example is making a best-attempt to preserve history
-when using Git. While Git does have commands like cherry-pick which allow the
-contents of a commit to be applied from one branch to another which are not
-candidates to merge without conflict (which is typically the case when merging
-a higher version into a lower version), this results in a duplication of that
-commit in history when the two trees are eventually merged together. While Git
-is smart enough to not attempt to re-apply the changes, history still contains
-the blemish.</p>
-<p>The purpose of this extravagant example is to outline, in the trivial case,
how
-the workflow decided upon for development is very important and has direct
-impact on the efficacy of the advanced commands bundled with Git.</p>
-<h2 id="proposed-workflow">Proposed Workflow</h2>
-<p>This is a summary of what has been agreed upon by vocal committers/PMC
members
-on <a href="mailto:d...@accumulo.apache.org";>d...@accumulo.apache.org</a>.
Enumeration of
-every possible situation out of the scope of this document. This document
-intends to lay the ground work to define the correct course of action
regardless
-of circumstances. Some concrete examples will be provided to ensure the
-explanation is clear.</p>
+ <p>The PMC of Apache Accumulo closed a vote on 2014/12/12 which adopted <a
href="http://semver.org/spec/v2.0.0.html";>Semantic Versioning 2.0.0</a> as
+the reference document on the meaning and requirements of subsequent releases
of Apache Accumulo. The definition
+of the public API is unchanged over previous releases and can be found in
section 9 of the <a
href="https://git-wip-us.apache.org/repos/asf?p=accumulo.git;a=blob;f=README;hb=refs/heads/master";>README</a>.</p>
+<p>The semantic versioning specification is included here:</p>
+<p>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.</p>
<ol>
<li>
-<p>Active development is performed concurrently over no less than two versions
- of Apache Accumulo at any one point in time. As such, the workflow must
- provide guidance on how and where changes should be made which apply to
- multiple versions and how to ensure that such changes are contained in all
- applicable versions.</p>
-</li>
-<li>
-<p>Releases are considered extremely onerous and time-consuming so no emphasis
- is placed on rapid iterations or development-cycles.</p>
-</li>
-<li>
-<p>New features typically have lengthy development cycles in which more than
- one developer contributes to the creation of the new feature from planning,
- to implementation, to scale testing. Mechanisms/guidance should be provided
- for multiple developers to teach contribute to a remote-shared resource.</p>
-</li>
-<li>
-<p>The repository should be the irrefutable, sole source of information
- regarding the development of Apache Accumulo, and, as such, should have
- best-efforts given in creating a clean, readable history without any single
- entity having to control all write access and changes (a proxy). In other
- words, the developers are the ones responsible for ensuring that previous
- releases are preserved to meet ASF policy, for not rewriting any public
- history of code not yet officially released (also ASF policy relevant) and
- for a best-effort to be given to avoid duplicative commits appearing in
- history created by the application of multiple revisions which have
- different identifying attributes but the same contents (git-rebase and
- git-cherry-pick).</p>
-</li>
-</ol>
-<h1 id="the-implementation">The implementation</h1>
-<h2 id="contributors">Contributors</h2>
-<p>Use the following steps, original derived from Apache Kafka's <a
href="https://cwiki.apache.org/confluence/display/KAFKA/Patch+submission+and+review#Patchsubmissionandreview-Simplecontributorworkflow";>simple
-contributor
-workflow</a>.</p>
-<p>To be specific, let's consider a contributor wanting to work on a fix for
the
-Jira issue ACCUMULO-12345 that affects 1.5.0 release.</p>
-<ol>
-<li>
-<p>Ensure you configured Git with your information</p>
-<p><code>git config --global user.name 'My Name' && git config
--global user.email
-'myn...@mydomain.com'</code></p>
-</li>
-<li>
-<p>Clone the Accumulo repository:</p>
-<p><code>git clone https://git-wip-us.apache.org/repos/asf/accumulo.git
accumulo</code></p>
-</li>
-<li>
-<p>or update your local copy:</p>
-<p><code>git fetch && git fetch --tags</code></p>
-</li>
-<li>
-<p>For the given issue you intend to work on, choose the 'lowest' fixVersion
- and create a branch for yourself to work in. This example is against the
next release of 1.5</p>
-<p><code>git checkout -b ACCUMULO-12345-my-work origin/1.5</code></p>
-</li>
-<li>
-<p>Make commits as you see fit as you fix the issue, referencing the issue name
- in the commit message:</p>
-<p><code>git commit -av</code></p>
-<p>Please include the ticket number at the beginning of the log message, and
-in the first line, as it's easier to parse quickly. For example:</p>
-<p><code>ACCUMULO-2428 throw exception when rename fails after
compaction</code></p>
-<p>Consider following the git log message format described in
-<a href="http://zachholman.com/talk/more-git-and-github-secrets/";>Zach
Holman's talk</a>
-(specifically slides 78-98, beginning at 15:20 into the video). Essentially,
-leave a short descriptive message in the first line, skip a line, and write
-more detailed stuff there, if you need to. For example:</p>
-<p><code>ACCUMULO-2194 Add delay for randomwalk Security teardown</code></p>
-<p><code>If two Security randomwalk tests run back-to-back, the second test
may see that the
-table user still exists even though it was removed when the first test was
torn down.
-This can happen if the user drop does not propagate through Zookeeper quickly
enough.
-This commit adds a delay to the end of the Security test to give ZK some
time.</code></p>
-</li>
-<li>
-<p>Assuming others are developing against the version you also are, as you
- work, or before you create your patch, rebase your branch against the remote
- to lift your changes to the top of your branch. The branch specified here
should be the same one you used in step 4.</p>
-<p><code>git pull --rebase origin 1.5</code></p>
-</li>
-<li>
-<p>At this point, you can create a patch file from the upstream branch to
- attach to the ACCUMULO-12345 Jira issue. The branch specified here should
be teh same one you used in step 4.</p>
-<p><code>git format-patch --stdout origin/1.5 >
ACCUMULO-12345.patch</code></p>
-</li>
-</ol>
-<p>An alternative to creating a patch is submitting a request to pull your
changes
-from some repository, e.g. Github. Please include the repository and branch
-name merge in the notice to the Jira issue, e.g.</p>
-<div class="codehilite"><pre><span class="n">repo</span><span
class="p">=</span><span class="n">git</span><span class="p">:</span><span
class="o">//</span><span class="n">github</span><span class="p">.</span><span
class="n">com</span><span class="o">/<</span><span
class="n">username</span><span class="o">>/</span><span
class="n">accumulo</span><span class="p">.</span><span class="n">git</span>
<span class="n">branch</span><span class="p">=</span><span
class="n">ACCUMULO</span><span class="o">-</span>12345
-</pre></div>
-
-
-<p>A second alternative is to use Github's "Pull Requests" feature against the
-<a href="https://github.com/apache/accumulo";>Apache Accumulo account</a>.
Notifications of
-new pull-requests from Github should automatically be sent to
-<a href="mailto:d...@accumulo.apache.org";>d...@accumulo.apache.org</a>.</p>
-<p>Ignoring specifics, contributors should be sure to make their changes
against
-the earlier version in which the fix is intended, <code>git-rebase</code>'ing
their
-changes against the upstream branch so as to keep their changes co-located and
-free of unnecessary merges.</p>
-<h2 id="developers">Developers</h2>
-<h3 id="primary-development">Primary Development</h3>
-<p>Primary development should take place in <code>master</code> which is to
contain the most
-recent, un-released version of Apache Accumulo. Branches exist for minor
releases
-for each previously released major version. </p>
-<p>Using long-lived branches that track a major release line simplifies
management and
-release practices. Developers are encouraged to make branches for their own
purposes,
-for large features, release candidates or whatever else is deemed useful.</p>
-<h3 id="reviewing-contributor-changes">Reviewing contributor changes</h3>
-<p>It is always the responsibility of committers to determine that a patch is
-intended and able to be contributed. From the
-<a href="http://www.apache.org/dev/new-committers-guide.html#cla";>new
committer's guide</a>:
-"Please take care to ensure that patches are original works which have been
-clearly contributed to the ASF in public. In the case of any doubt (or when a
-contribution with a more complex history is presented) please consult your
-project PMC before committing it."</p>
-<p>Extra diligence may be necessary when code is contributed via a pull
request.
-Committers should verify that the contributor intended to submit the code as a
-Contribution under the <a
href="http://www.apache.org/licenses/LICENSE-2.0.txt";>Apache License</a>.
-When pulling the code, committers should also verify that the commits pulled
match the
-list of commits sent to the Accumulo dev list in the pull request.</p>
-<h4 id="patches">Patches</h4>
-<p>Developers should use the following steps to apply patches from
-contributors:</p>
-<ol>
-<li>
-<p>Checkout the branch for the major version which the patch is intended:</p>
-<p><code>git checkout 1.5</code></p>
-</li>
-<li>
-<p>Verify the changes introduced by the patch:</p>
-<p><code>git apply --stat ACCUMULO-12345.patch</code></p>
-</li>
-<li>
-<p>Verify that the patch applies cleanly:</p>
-<p><code>git apply --check ACCUMULO-12345.patch</code></p>
-</li>
-<li>
-<p>If all is well, apply the patch:</p>
-<p><code>git am --signoff < ACCUMULO-12345.patch</code></p>
-</li>
-<li>
-<p>When finished, push the changes:</p>
-<p><code>git push origin 1.5</code></p>
-</li>
-<li>
-<p>Merge where appropriate:</p>
-<p><code>git checkout master && git merge 1.5</code></p>
-</li>
-</ol>
-<h4 id="github-pull-requests">Github Pull-Requests</h4>
-<p>If the contributor submits a repository and branch to pull
-from, the steps are even easier:</p>
-<ol>
-<li>
-<p>Add their repository as a remote to your repository</p>
-<p><code>git remote add some_name ${repository}</code></p>
-</li>
-<li>
-<p>Fetch the refs from the given repository</p>
-<p><code>git fetch ${repository}</code></p>
-</li>
-<li>
-<p>Merge in the given branch to your local branch</p>
-<p><code>git merge some_name/${branch}</code></p>
-</li>
-<li>
-<p>Delete the remote:</p>
-<p><code>git remote remove some_name</code></p>
-</li>
-</ol>
-<p>If the branch doesn't fast-forward merge, you likely want to inform the
-contributor to update their branch to avoid the conflict resolution and merge
-commit. See the <a
href="http://git-scm.com/book/en/Git-Branching-Basic-Branching-and-Merging";>Git
-manual</a>
-for more information on merging. When merging a pull-request, it's best to
<strong>not</strong>
-include a signoff on the commit(s) as it changes the final commit ID in the
-Accumulo repository. This also has the negative of not automatically closing
-the Pull-Request when the changes are made public.</p>
-<h3 id="feature-branches">Feature Branches</h3>
-<p>Ease in creating and using feature branches is a desirable merit which Git
-provides with little work. Feature branches are a great way in which developers
-to work on multiple, long-running features concurrently, without worry of
-mixing code ready for public-review and code needing more internal work.
-Additionally, this creates an easily consumable series of commits in which
-other developers can track changes, and see how the feature itself evolved.</p>
-<p>To prevent developers' feature branches from colliding with one another, it
was
-suggested to impose a "hierarchy" in which shared feature branches are prefixed
-with <code><apache_id>/ACCUMULO-<issue#>[-description]</code>.</p>
-<ol>
-<li>
-<p>Create a branch off of <code>master</code>.</p>
-<p><code>git checkout <apache_id>/ACCUMULO-<issue#>
master</code></p>
-</li>
-<li>
-<p>Create the feature, commiting early and often to appropriately outline the
-"story" behind the feature and it's implementation.</p>
-</li>
-<li>
-<p>As long as you have not collaborating with others, <code>git-rebase</code>
your feature
-branch against upstream changes in <code>master</code></p>
-<p><code>git fetch && git rebase origin/master</code></p>
-</li>
-<li>
-<p>If you are actively collaborating with others, you should be nice and not
-change their history. Use <code>git-merge</code> instead.</p>
-<p><code>git fetch && git merge origin/master</code></p>
-</li>
-<li>
-<p>Continue steps 2 through 4 until the feature is complete.</p>
-</li>
-<li>
-<p>Depending on the nature, duration and history of the changes in your feature
-branch, you can choose to:</p>
-<ul>
-<li>
-<p><strong>'Simple' Merge</strong>: </p>
-<p><code>git checkout master && git merge
<apache_id>/ACCUMULO-<issue#></code></p>
-</li>
-<li>
-<p><strong>Rebase and merge</strong> -- keeps all feature-branch commits
- co-located: </p>
-<p><code>git fetch && git rebase origin/master && git checkout
master && git merge <apache_id>/ACCUMULO-<issue#></code></p>
-</li>
-<li>
-<p><strong>Merge with squash</strong> -- feature branch history is a mess,
just make one commit
- with the lump-sum of your feature branch changes: </p>
-<p><code>git checkout master && git merge --squash
<apache_id>/ACCUMULO-<issue#></code></p>
-</li>
-</ul>
-</li>
-</ol>
-<h3 id="changes-which-affect-multiple-versions-aka-merging">Changes which
affect multiple versions (a.k.a. merging)</h3>
-<p>Merging can be a very confusing topic for users switching to Git, but it
can be
-summarized fairly easily.</p>
-<ol>
-<li>
-<p><strong>Precondition</strong>: choose the right branch to start! (lowest,
applicable version
- for the change)</p>
-</li>
-<li>
-<p>Get your changes fixed for that earliest version.</p>
-</li>
-<li>
-<p>Switch to the next highest version which future minor versions will be
- released (non-EOL major release series).</p>
-</li>
-<li>
-<p><code>git-merge</code> the branch from #1 into the current.</p>
+<p>Software using Semantic Versioning MUST declare a public API. This API
could be declared in the code itself or exist
+strictly in documentation. However it is done, it should be precise and
comprehensive.</p>
</li>
<li>
-<p>In the face of conflicts, use options from <code>git-merge</code> to help
you.</p>
-<ul>
-<li><code>git checkout new-version && git merge --stat
old-version</code></li>
-<li><code>git checkout new-version && git merge --no-commit
old-version</code></li>
-</ul>
+<p>A normal version number MUST take the form X.Y.Z where X, Y, and Z are
non-negative integers, and MUST NOT contain
+leading zeroes. X is the major version, Y is the minor version, and Z is the
patch version. Each element MUST increase
+numerically. For instance: 1.9.0 -> 1.10.0 -> 1.11.0.</p>
</li>
<li>
-<p>Treat your current branch as the branch from #2, and repeat from #2.</p>
+<p>Once a versioned package has been released, the contents of that version
MUST NOT be modified. Any modifications MUST
+be released as a new version.</p>
</li>
-</ol>
-<p>When merging changes across major releases, there is always the possibility
of
-changes which are applicable/necessary in one release, but not in any future
-releases, changes which are different in implementation due to API changes, or
-any number of other cases. Whatever the actual case is, the developer who made
-the first set of changes (you) is the one responsible for performing the merge
-through the rest of the active versions. Even when the merge may results in a
-zero-length change in content, this is incredibly important to record as you
-are the one who knows that this zero-length change in content is correct!</p>
-<h2 id="release-management">Release Management</h2>
-<p>Releases, although not a day to day task, have their own unique steps which
are
-to be followed. Releases can be categorized in to minor and major releases.</p>
-<h3 id="a-minor-release">A minor release</h3>
-<p>A minor release is some set of changes <code>z'</code> on top of a version
<code>x.y.z</code>.
-Typically, <code>z'</code> is simply <code>z + 1</code>, e.g. given a release
named '1.6.0', and the
-next minor release is '1.6.1'. These changes for <code>z'</code> should not
break any
-client code which works against <code>z</code> and should absolutely not
change the public
-API.</p>
-<p>By convention, the branch containing the changes <code>z'</code> should be
named
-<code>x.y</code> (where the changes for <code>z'</code> are commits since
<code>x.y.z</code>. The steps to take are as follows:</p>
-<ol>
-<li>Prepare the release candidate. <a href="/governance/releasing.html">Release
- Guide</a>, <a href="/releasing.html">Maven
- Instructions</a></li>
-<li>Create a branch for the release candidate from the <code>x.y</code> branch,
- named something like <code>x.y.z'-RCN</code>.</li>
-<li>Test and Vote</li>
-<li>Create a GPG-signed tag with the correct final name:
<code>x.y.z'</code></li>
-<li>Push a delete of the remote branch <code>x.y.z'-RCN</code></li>
-</ol>
-<p>This process is not firm and should not be viewed as requirements for
making a release.
-The release manager is encouraged to make use branches/tags in whichever way
is best.</p>
-<h3 id="a-major-release">A major release</h3>
-<p>A major release is a release in which multiple new features are introduced
-and/or the public API are modified. The major release <code>y'</code>, even
when the
-client API is not modified, will typically contain many new features and
-functionality above the last release series <code>y</code>. A major release
also resets
-the <code>z</code> value back to <code>0</code>.</p>
-<p>The steps to create a new major release are very similar to a minor
release:</p>
-<ol>
-<li>Prepare the release candidate. <em>reference release instructions</em></li>
-<li>Create a tag of the release candidate from the <code>x.y</code> branch,
- named something like <code>x.y.0-RCN</code>.</li>
-<li>Test and Vote</li>
-<li>Create a GPG-signed tag with the correct final name:
<code>x.y.0</code></li>
-<li>Push a delete of the remote branch <code>x.y.0-RCN</code></li>
-</ol>
-<h1 id="the-infrastructure">The infrastructure</h1>
-<p>This section deals with the changes that must be requested through INFRA. As
-with any substantial INFRA request, the VOTE and result from the mailing should
-be referenced so INFRA knows that the request has been acknowledged. Likely, a
-PMC member should be the one to submit the request.</p>
-<h2 id="repositories">Repositories</h2>
-<p>I believe that we will need multiple repositories to best align ourselves
with
-how we currently track "Accumulo" projects. The repositories follow:</p>
-<ol>
<li>
-<p>The main source tree. This will track the standard trunk, branches, tags
- structure from Subversion for Apache Accumulo.</p>
+<p>Major version zero (0.y.z) is for initial development. Anything may change
at any time. The public API should not be
+considered stable.</p>
</li>
<li>
-<p>One repository for every project in
- <a href="https://svn.apache.org/repos/asf/accumulo/contrib";>contrib</a>:
Accumulo-BSP,
- Instamo Archetype, and the Wikisearch project. Each of these
- are considered disjoint from one another, and the main source tree, so they
- each deserve their own repository.</p>
+<p>Version 1.0.0 defines the public API. The way in which the version number
is incremented after this release is dependent
+on this public API and how it changes.</p>
</li>
-</ol>
-<p>Given the list of repositories that currently exist on the <a
href="https://git-wip-us.apache.org/repos/asf";>ASF
-site</a> and a brief search over INFRA
-tickets, multiple repositories for a single Apache project is not an issue.
-Having this list when making the initial ticket will likely reduce the amount
-of work necessary in opening multiple INFRA tickets.</p>
-<h2 id="mirroring">Mirroring</h2>
-<p>It should be noted in the INFRA requst that each repository will also need
to
-be configured to properly mirror to the <a
href="https://github.com/apache";>ASF Github</a>
-account to provide the same functionality with current have via the git+svn
-mirror. This should be noted in the INFRA request. Same change needs to be
-applied for the <a href="http://git.apache.org";>Apache hosted</a>
mirror'ing.</p>
-<h2 id="mailing-lists">Mailing lists</h2>
-<p>It should be noted in the INFRA request that commit messages should be sent
to
-<a href="mailto:commits@accumulo.apache.org";>commits@accumulo.apache.org</a>.
The subject
-can be decided on using the <a
href="https://git-wip-us.apache.org/docs/switching-to-git.html#contents";>provided
-variables</a>.</p>
-<h1 id="examples">Examples</h1>
-<p>For the sake of clarity, some examples of common situations are included
below.</p>
-<h2 id="releasing-160">Releasing 1.6.0</h2>
-<ol>
<li>
-<p>Branch from <code>master</code> to <code>1.6</code></p>
-<p><code>git checkout master && git branch 1.6</code></p>
+<p>Patch version Z (x.y.Z | x > 0) MUST be incremented if only backwards
compatible bug fixes are introduced. A bug fix
+is defined as an internal change that fixes incorrect behavior.</p>
</li>
<li>
-<p>Tag <code>1.6.0-RC1</code> from the just created <code>1.6</code> branch</p>
-<p><code>git tag 1.6.0-RC1 1.6</code></p>
+<p>Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backwards
compatible functionality is introduced to the
+public API. It MUST be incremented if any public API functionality is marked
as deprecated. It MAY be incremented if
+substantial new functionality or improvements are introduced within the
private code. It MAY include patch level changes.
+Patch version MUST be reset to 0 when minor version is incremented.</p>
</li>
<li>
-<p>Test, vote, etc. and tag from 1.6.0-RC1</p>
-<p><code>git -s tag 1.6.0 1.6.0-RC1</code></p>
+<p>Major version X (X.y.z | X > 0) MUST be incremented if any backwards
incompatible changes are introduced to the public
+API. It MAY include minor and patch level changes. Patch and minor version
MUST be reset to 0 when major version is incremented.</p>
</li>
<li>
-<p>Delete the RC tag, if desired.</p>
-<p><code>git tag -d 1.6.0-RC1 && git push --delete origin
1.6.0-RC1</code></p>
+<p>A pre-release version MAY be denoted by appending a hyphen and a series of
dot separated identifiers immediately following
+the patch version. Identifiers MUST comprise only ASCII alphanumerics and
hyphen [0-9A-Za-z-]. Identifiers MUST NOT be empty.
+Numeric identifiers MUST NOT include leading zeroes. Pre-release versions have
a lower precedence than the associated normal
+version. A pre-release version indicates that the version is unstable and
might not satisfy the intended compatibility requirements
+as denoted by its associated normal version. Examples: 1.0.0-alpha,
1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92.</p>
</li>
<li>
-<p>Ensure <code>master</code> contains all features and fixes from
<code>1.6.0</code></p>
-<p><code>git checkout master && git merge 1.6</code></p>
+<p>Build metadata MAY be denoted by appending a plus sign and a series of dot
separated identifiers immediately following
+the patch or pre-release version. Identifiers MUST comprise only ASCII
alphanumerics and hyphen [0-9A-Za-z-]. Identifiers MUST
+NOT be empty. Build metadata SHOULD be ignored when determining version
precedence. Thus two versions that differ only in the
+build metadata, have the same precedence. Examples: 1.0.0-alpha+001,
1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85.</p>
</li>
<li>
-<p>Update the project version in <code>master</code> to 1.7.0-SNAPSHOT</p>
+<p>Precedence refers to how versions are compared to each other when ordered.
Precedence MUST be calculated by separating
+the version into major, minor, patch and pre-release identifiers in that order
(Build metadata does not figure into precedence).
+Precedence is determined by the first difference when comparing each of these
identifiers from left to right as follows: Major,
+minor, and patch versions are always compared numerically. Example: 1.0.0 <
2.0.0 < 2.1.0 < 2.1.1. When major, minor, and patch
+are equal, a pre-release version has lower precedence than a normal version.
Example: 1.0.0-alpha < 1.0.0. Precedence for two
+pre-release versions with the same major, minor, and patch version MUST be
determined by comparing each dot separated identifier
+from left to right until a difference is found as follows: identifiers
consisting of only digits are compared numerically and
+identifiers with letters or hyphens are compared lexically in ASCII sort
order. Numeric identifiers always have lower precedence
+than non-numeric identifiers. A larger set of pre-release fields has a higher
precedence than a smaller set, if all of the
+preceding identifiers are equal. Example: 1.0.0-alpha < 1.0.0-alpha.1 <
1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 <
+1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0.</p>
</li>
</ol>
</div>
