Re: [Hyperledger Project TSC] Hyperledger Release Taxonomy v0.1

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:


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 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.


On Thu, Jul 14, 2016 at 10:52 AM, Christopher B Ferris via hyperledger-tsc <hyperledger-tsc@...> wrote:

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.



Christopher Ferris

IBM Distinguished Engineer, CTO Open Technology

IBM Cloud, Open Technologies

email: chrisfer@...

twitter: @christo4ferris


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 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.)
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 Behlendorf

Executive Director at the Hyperledger Project


Twitter: @brianbehlendorf


hyperledger-tsc mailing list


hyperledger-tsc mailing list

hyperledger-tsc mailing list

Join to automatically receive all group messages.