Make number grows at the same pace of quantum server will help guys to
know the relationship between them.
I even consider using 7 for G, 8 for H. We can also skip some number if
we have no big change at all.
for example,
If during G dev, we have no change for G1, and G2, we will have no 3.1
and 3.2, We go directly to 3.3 for G3
On 02/05/2013 08:09 AM, Mark McClain wrote:
I'd like to suggest that we go with a much slower progression of numbers.
Given an X.Y.Z numbering scheme.
X - Increment X when the library is changed in backwards incompatible ways
(i.e. a developer must alter their code that uses the library).
Y - Increment when major new features on each coordinated OpenStack release
Z - Increment when we make bug fix releases to the stable X.Y branch.
mark
On Feb 4, 2013, at 6:49 PM, gong yong sheng <gong...@linux.vnet.ibm.com> wrote:
HI,
Qunatum client is used by nova and horizon from pypi repo.
For them to use new API and extension in the quantum server during dev, we have
to bump its version on pypi repo.
I recommend to use the following version numbers:
G's big release number is 3,
H's 4,
I's 5.
3.1 for G1, 3.2 for G2, 3.3 for G3, 3.4 for R1, 3.4 for R2, and so on
during development, if we need release quantum client, we use third number:
3.1.0, 3.1.1 and so on
any ideas?
Yong Sheng Gong
--
Mailing list: https://launchpad.net/~quantum-core
Post to : quantum-core@lists.launchpad.net
Unsubscribe : https://launchpad.net/~quantum-core
More help : https://help.launchpad.net/ListHelp
--
Mailing list: https://launchpad.net/~quantum-core
Post to : quantum-core@lists.launchpad.net
Unsubscribe : https://launchpad.net/~quantum-core
More help : https://help.launchpad.net/ListHelp
