Date
1 - 10 of 10
[Hyperledger Project TSC] Hyperledger Release Taxonomy v0.1
|
Brian Behlendorf
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. Developer Preview: 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) Alpha: 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. Beta: 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. Production: 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. Example: 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. Thoughts? Brian -- Brian Behlendorf Executive Director at the Hyperledger Project bbehlendorf@... Twitter: @brianbehlendorf |
|
|
|
I love the design. Just throw some possible options. While use "x.y-[alpha, beta, rc]-z" for tracking special release tag. examples: 1.0-alpha-1 1.0-beta-2 2.0-rc-1 And agree with minor version number as fix to the major one, like 2.1.0 is fix for 2.0.0. Would this be easier to understand literally? And I guess major+minor version number should enough for the release tracking, while also agree to align with linux style, as it's LF supported! Any thoughts? Thanks! On Thu, Jun 23, 2016 at 2:00 PM, Brian Behlendorf via hyperledger-tsc <hyperledger-tsc@...> wrote:
--
Best wishes!
Baohua |
|
|
|
Elisha Kendagor <kendagor@...>
It looks good. When a branch occurs does the branched off build continue to iterate forward? Such that 1.0.1, 1.1.1,1.0.2, 1.1.2 continue running in parallel? I would like to propose a more converged versioning so that once 1.1.x which appears newer than 1.0.x branches out, then 1.0.x and other lower branched versions have only critical fixes which get merged into the higher branched versions and if necessary have an overall even higher conversion branch where the lower branches converge into, so that 1.0.x, 1.1.x, 1.2.x converge into perhaps 2.0.x. I hope that makes sense 😊. Opinions?  Thanks  Elisha   From: Brian Behlendorf via hyperledger-tsc
Sent: Thursday, June 23, 2016 02:01 To: 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. -- Brian Behlendorf Executive Director at the Hyperledger Project bbehlendorf@... Twitter: @brianbehlendorf  |
|
|
|
Brian Behlendorf
On 06/23/2016 01:58 AM, Baohua Yang wrote:
use "x.y-[alpha, beta, rc]-z" for tracking special release tag.I've modified my proposal to include this numbering scheme as an alternative; on the call today we should pick one. On 06/23/2016 08:17 AM, Elisha Kendagor via hyperledger-tsc wrote: It looks good. When a branch occurs does the branched off buildcontinue to iterate forward? would like to propose a more converged versioning so that once 1.1.x which appears newer than 1.0.x branches out, then 1.0.x and other lower branched versions have only critical fixes which get merged into the higher branched versions and if necessary have an overall even higher conversion branch where the lower branches converge into, so that 1.0.x, 1.1.x, 1.2.x converge into perhaps 2.0.x. I hope that makes sense 😊. Opinions? Yes, they'd run in parallel until such time as the developers decide to EOL a particular branch. So for example a critical security issue that affects 1.1.22 (older) and 1.2.3 (newer) would necessitate a 1.1.23 and a 1.2.4. Generally you don't converge the tail end of those branches, you just gradually give them fewer and fewer fixes, though any branch not yet explicitly EOL'd should have any security-related fix applied unless it requires major refactoring and risk. I suspect our customers will tend to demand LTS (long-term support) branches like Ubuntu has. Brian -- Brian Behlendorf Executive Director at the Hyperledger Project bbehlendorf@... Twitter: @brianbehlendorf |
|
|
|
Christopher B Ferris <chrisfer@...>
Sorry for not chiming in earlier... vacation will do that to ya (lose track of emails you intended to reply to).
Why not use semver [1]. I like the approach that Brian suggested, but I worry that we'd have to explain to the world. So, this would be aligned with Brian's suggestion but we would use the terms in the release identifier. Rather than focus on release numbering to signify the alpha or beta, just append the -alpha -beta -rcN qualifier. This gives us better flexibility over what we consider to be a release. Seems to me that we should be able to have a number of releases that are backwardly compatible. Using semver allows us to ascertain backwards compatibility in an automated manner. [1] http://semver.org/ Cheers, Christopher Ferris IBM Distinguished Engineer, CTO Open Technology IBM Cloud, Open Technologies email: chrisfer@... twitter: @christo4ferris blog: https://developer.ibm.com/opentech/author/chrisfer/ phone: +1 508 667 0402 -----hyperledger-tsc-bounces@... wrote: -----To: hyperledger-tsc@... From: Brian Behlendorf via hyperledger-tsc Sent by: hyperledger-tsc-bounces@... Date: 07/14/2016 08:15AM Subject: Re: [Hyperledger Project TSC] Hyperledger Release Taxonomy v0.1 On 06/23/2016 01:58 AM, Baohua Yang wrote: use "x.y-[alpha, beta, rc]-z" for tracking special release tag.I've modified my proposal to include this numbering scheme as an alternative; on the call today we should pick one. On 06/23/2016 08:17 AM, Elisha Kendagor via hyperledger-tsc wrote: > It looks good. When a branch occurs does the branched off build continue to iterate forward? > > Such that 1.0.1, 1.1.1,1.0.2, 1.1.2 continue running in parallel? I would like to propose a more converged versioning so that once 1.1.x which appears newer than 1.0.x branches out, then 1.0.x and other lower branched versions have only critical fixes which get merged into the higher branched versions and if necessary have an overall even higher conversion branch where the lower branches converge into, so that 1.0.x, 1.1.x, 1.2.x converge into perhaps 2.0.x. I hope that makes sense 😊. Opinions? Yes, they'd run in parallel until such time as the developers decide to EOL a particular branch. So for example a critical security issue that affects 1.1.22 (older) and 1.2.3 (newer) would necessitate a 1.1.23 and a 1.2.4. Generally you don't converge the tail end of those branches, you just gradually give them fewer and fewer fixes, though any branch not yet explicitly EOL'd should have any security-related fix applied unless it requires major refactoring and risk. I suspect our customers will tend to demand LTS (long-term support) branches like Ubuntu has. Brian -- Brian Behlendorf Executive Director at the Hyperledger Project bbehlendorf@... Twitter: @brianbehlendorf _______________________________________________ hyperledger-tsc mailing list hyperledger-tsc@... https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc |
|
|
|
Shawn Amundson
Won't make the TSC meeting, but some thoughts. It would be nice to use 0.99.x instead of 0.9.x, in case we want to have 0.8.x, 0.9.x, 0.10.x, 0.11.x, etc. within our individual projects. Unlikely to use 0.99.x in that sequence. We are considering abandoning our current use of 1.1.x for Sawtooth Lake components and bump back down to the 0.x range to conform to this spec.  (As we only have very few tags anyway.) -Shawn On Thu, Jul 14, 2016 at 7:15 AM, Brian Behlendorf via hyperledger-tsc <hyperledger-tsc@...> wrote: On 06/23/2016 01:58 AM, Baohua Yang wrote: |
|
|
|
Shawn Amundson
+1 on using semver to the extent practically possible. Also, +1 to appending -devN, -alpha, -beeta, -rcN. as appropriate after the X.Y.Z. These get sorted properly by several packaging system "1.0.0-alpha1" is before "1.0.0" for example (for RPMs, etc.). -Shawn On Thu, Jul 14, 2016 at 8:54 AM, Christopher B Ferris via hyperledger-tsc <hyperledger-tsc@...> wrote: Sorry for not chiming in earlier... vacation will do that to ya (lose track of emails you intended to reply to). |
|
|
|
Brian Behlendorf
+1 to Semver, I didn't realize it
existed and was trying to replicate it, poorly. So all we'd need
to agree to is that all Hyperledger projects must (should?) use
the semver.org spec.
Brian On 07/14/2016 07:00 AM, Shawn Amundson wrote:
-- Brian Behlendorf Executive Director at the Hyperledger Project bbehlendorf@... Twitter: @brianbehlendorf |
|
|
|
Christopher B Ferris <chrisfer@...>
Shawn,
toggle quoted message
Show quoted text
Thanks for sharing this. I also agree that the -devN (number of commits since the tag) is very appropriate for publishing artefacts to the likes of npm, dockerhub, pypi, etc. The one point I'd make is that semver suggests that build metadata be appended with a '+' [1] whereas git describe would append the number of commits and sha with a '-' e.g. 0.5-developer-preview-298-g98f3b6f. I would note that that claus is a 'MAY' so I think that we're still conformant with the standard. Given that this is what STL is doing presently, I think it makes a world of sense to continue this course for all Hyperledger projects unless there is disagreement and an alternative proposal. I'd like to see the other project maintainers chime in on this discussion. [1] http://semver.org/#spec-item-10 Cheers, Christopher Ferris IBM Distinguished Engineer, CTO Open Technology IBM Cloud, Open Technologies email: chrisfer@... twitter: @christo4ferris blog: https://developer.ibm.com/opentech/author/chrisfer/ phone: +1 508 667 0402 -----hyperledger-tsc-bounces@... wrote: -----To: Brian Behlendorf <bbehlendorf@...> From: Shawn Amundson via hyperledger-tsc Sent by: hyperledger-tsc-bounces@... Date: 07/14/2016 10:20AM Cc: hyperledger-tsc@... Subject: Re: [Hyperledger Project TSC] Hyperledger Release Taxonomy v0.1 Won't make the TSC meeting, but some thoughts. For our python modules, we are doing something similar to the openstack project where we have X.Y.Z-devN where N is the number of commits since X.Y.Z-1. This makes sure that we don't produce artifacts with the same version as the tagged version. This uses get describe and all the setup.py files in sawtooth repos implement this. If you are on a tagged version, then it properly uses X.Y.Z. This has worked well for Jenkins builds. It would be nice to use 0.99.x instead of 0.9.x, in case we want to have 0.8.x, 0.9.x, 0.10.x, 0.11.x, etc. within our individual projects. Unlikely to use 0.99.x in that sequence. We are considering abandoning our current use of 1.1.x for Sawtooth Lake components and bump back down to the 0.x range to conform to this spec. (As we only have very few tags anyway.) -Shawn On Thu, Jul 14, 2016 at 7:15 AM, Brian Behlendorf via hyperledger-tsc <hyperledger-tsc@...> wrote:
On 06/23/2016 01:58 AM, Baohua Yang wrote: use "x.y-[alpha, beta, rc]-z" for tracking special release tag. I've modified my proposal to include this numbering scheme as an alternative; on the call today we should pick one. On 06/23/2016 08:17 AM, Elisha Kendagor via hyperledger-tsc wrote: It looks good. When a branch occurs does the branched off build continue to iterate forward? Such that 1.0.1, 1.1.1,1.0.2, 1.1.2 continue running in parallel? I would like to propose a more converged versioning so that once 1.1.x which appears newer than 1.0.x branches out, then 1.0.x and other lower branched versions have only critical fixes which get merged into the higher branched versions and if necessary have an overall even higher conversion branch where the lower branches converge into, so that 1.0.x, 1.1.x, 1.2.x converge into perhaps 2.0.x. I hope that makes sense 😊. Opinions? Yes, they'd run in parallel until such time as the developers decide to EOL a particular branch. So for example a critical security issue that affects 1.1.22 (older) and 1.2.3 (newer) would necessitate a 1.1.23 and a 1.2.4. Generally you don't converge the tail end of those branches, you just gradually give them fewer and fewer fixes, though any branch not yet explicitly EOL'd should have any security-related fix applied unless it requires major refactoring and risk. I suspect our customers will tend to demand LTS (long-term support) branches like Ubuntu has. Brian -- Brian Behlendorf Executive Director at the Hyperledger Project bbehlendorf@... Twitter: @brianbehlendorf _______________________________________________ hyperledger-tsc mailing list hyperledger-tsc@... https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc _______________________________________________ hyperledger-tsc mailing list hyperledger-tsc@... https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc |
|
|
|
Shawn Amundson
We do add the git information as well to the version number.  (And apparently use -git, not -dev for Jenkins - forgot about that.)  So our full deb filename for example ends up looking like this: python-sawtooth-core_1.1.1-git178.gcdd74e5.dirty-1_amd64.deb This reads as "the 178th commit after v1.1.0, commit id gcdd74e5 with a dirty working directory".  (.dirty doesn't ever appear in Jenkins builds.)  If the release is properly tagged, a build on that commit id will result in the expected X.Y.Z build only, without the pre-release items added. This makes our pre-release version component "git178.gcdd74e5.dirty" in this case, which (I believe) conforms to semvar. We don't include any build metadata (which, presumably would be the Jenkins build id, which we aren't concerned about). I did play around a bit with attempting to add build metadata with "+" but it seemed to cause issues (don't recall the specifics). The pragmatic part is that we do have some constrains in what works well for the different packaging formats (deb, rpm, etc.) and so we might have slightly different variants to make sure we conform for those target systems. We note, for example, that on Windows we get an warning out of setup.py which hints that we might not be doing quite the right thing in that context. The primary goals of the above:  - Make sure we have are X.Y.Z version there (1.1.1 in the example above, the *next* release)  - Make sure we avoid confusion between real release packages and packages build between tags  - Make sure we can upgrade properly between versions (with apt-get for example)  - Make sure we can always have a reasonable chance to correlate a build artifact to the commit id  - Ideally, all the things semver attempts to cover (which requires significant project discipline on APIs) Note that semver and the above detail is really heavily related to packaging/tagging specifics. When we talk to the rest of the community, in release notes and such, or informally, we mostly care about new X.Y branches and X.Y.Z point releases. -Shawn On Thu, Jul 14, 2016 at 10:52 AM, Christopher B Ferris via hyperledger-tsc <hyperledger-tsc@...> wrote: Shawn, |
|
|