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
