1. Messages
  2. [Hyperledger Project TSC] Hyperledger Release Taxonomy v0.1

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

Shawn Amundson
 

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
Join {toc@lists.hyperledger.org to automatically receive all group messages.