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