I'll get this into a proper place on the wiki or github later, but
drafting this now while on the plane, for discussion at tomorrow's
Releases at the Hyperledger Project are done according to the
following common taxonomy. This is to help users who are familiar
with one HLP effort understand the self-proclaimed state of maturity
of another project. Note that this is *not* about exiting from the
incubator, though a beta or production release should not be made
while still in incubation.
Not feature complete, but most functionality implemented, and any
missing functionality that is committed for the production release
is identified and there are specific people working on those
features. Not heavily performance tuned, but performance testing
has started, and the first few hotspots identified, perhaps even
addressed. No "highest priority" issues in an unclosed state.
First-level developer documentation provided to help new developers
up the learning curve.
Naming convention: 0.x where x is < 8 (Developer Preview is not
used after it hits 1.0)
Feature complete, for all features committed to the production
release. Ready for Proof of Concept-level deployments. Performance
can be characterized in a predictable way, so that basic PoC's can
be done without risk of embarrassing performance. APIs documented.
First attempts at end-user documentation, developer docs further
advanced. No "highest priority" issues in an unclosed state.
Naming convention: y.8.x, where y is 0, 1, 2 (basically the last
production release) and x is the iteration of the alpha release.
Feature complete for all features committed to the production
release, perhaps with optional features when safe to add. Ready for
Pilot-level engagements. Performance is very well characterized and
active optimizations are being done, with a target set for the
Production release. No "highest priority" or "high priority" bugs
unclosed. Dev docs complete; end-user docs mostly done.
Naming convention: y.9.x, where y is 0, 1, 2 (basically the last
production release) and x is the iteration of the beta release.
An exact copy of the last iteration in the beta cycle, for a
reasonable length of time (2 weeks?) during which no new highest or
high priority bugs discovered, where end-user docs are considered
complete, and performance/speed goals have been met. Ready for
Naming convention: y.z.x, where y is the production release level
(1, 2, 3, etc), z is the branch level (for minor improvements), and
x is the iteration of the current branch.
Today's Fabric "Developer Preview" release is 0.5. It could
continue to 0.6, 0.7, 0.7.1....
but when it's ready for Alpha, we call it 0.8, iterating to 0.8.1,
When it's ready for beta, 0.9, 0.9.1, 0.9.2, etc.
And when we are ready for production, 1.0.0.
A bugfix patch release or other small fixups, 1.0.1, 1.0.2, etc.
A branch would be called for when there is something small that
changes behavior in some visible way: 1.1.0, 1.1.1, 1.2.0, 1.2.1,
And when it's time for a significant refactoring or rewrite or major
new functionality, we go back into the cycle, but missing the
1.8.0 is the alpha for 2.0
1.9.0 is the beta for 2.0
2.0.0 is the production release.
Executive Director at the Hyperledger Project