From: Brian Behlendorf via hyperledger-tscSent:
Thursday, June 23, 2016 02:01To: hyperledger-tsc@...Subject:
[Hyperledger Project TSC] Hyperledger Release Taxonomy v0.1
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 TSC.
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 Production-level engagements.
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, 0.8.2, etc.
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, etc.
And when it's time for a significant refactoring or rewrite or major new functionality, we go back into the cycle, but missing the "Developer Preview":
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