add content on versioning approach.
This commit is contained in:
@@ -0,0 +1,54 @@
|
|||||||
|
Versioning
|
||||||
|
=====
|
||||||
|
|
||||||
|
For releases we will follow semantic versioning approach. (http://semver.org/)
|
||||||
|
|
||||||
|
Semantic Versioning
|
||||||
|
===================
|
||||||
|
|
||||||
|
Semantic versioning is a very simple scheme built around the X.Y.Z-buildNo concept (for example 2.6.0-x or 2.6.0-BUILD-SNAPSHOT):
|
||||||
|
|
||||||
|
Increment Z when you fix something
|
||||||
|
Increment Y when you add a new feature
|
||||||
|
Increment X when you break backwards-compatibility or add major features
|
||||||
|
Use the buildNo to differentiate different builds off the same branch, and to differentiate between development, test and production builds.
|
||||||
|
|
||||||
|
Version structure
|
||||||
|
|
||||||
|
{number}.{release_type}
|
||||||
|
|
||||||
|
where {number} is further broken down as {major}.{minor}.{micro}.
|
||||||
|
|
||||||
|
Examples:
|
||||||
|
|
||||||
|
1.0.0.BUILD-SNAPSHOT
|
||||||
|
1.0.0.M1
|
||||||
|
1.0.0.RC1
|
||||||
|
1.0.0.RELEASE
|
||||||
|
|
||||||
|
Number semantics
|
||||||
|
|
||||||
|
major/minor/micro semantics may have some variance across projects but in general this is what we mean.
|
||||||
|
|
||||||
|
In general:
|
||||||
|
|
||||||
|
a major version suggests many significant new features, an associated marketing campaign, and possible breaking of backward compatibility.
|
||||||
|
a minor version may also contain serious new features, but should not break compatibility. You can expect minor releases every 1-3 months.
|
||||||
|
a micro version typically contains many bug fixes and improvements and perhaps several smaller new features. You can expect micro version approximately every 5-20 days (depending on bugs or suggested improvements).
|
||||||
|
|
||||||
|
Order matters
|
||||||
|
|
||||||
|
Notice that the following sequence of versions is in ordered ascending both alphabetically and toward GA:
|
||||||
|
|
||||||
|
1.0.0.BUILD-SNAPSHOT
|
||||||
|
1.0.0.M1
|
||||||
|
1.0.0.RC1
|
||||||
|
1.0.0.RELEASE
|
||||||
|
|
||||||
|
What You Should Install Where
|
||||||
|
|
||||||
|
As a rule of thumb …
|
||||||
|
|
||||||
|
Snapshot or Milestone versions should only be installed on dev boxes and integration environments. They shouldn’t be deployed to any of the dedicated test environments.
|
||||||
|
Release candidates should be installed in the dedicated test environments. In an emergency, a release candidate can be installed into the production environment.
|
||||||
|
Production releases can be installed anywhere - and they are the only kind of build that should be installed into the production environment.
|
||||||
Reference in New Issue
Block a user