Is there any kind of consistent versioning used for clients by other OpenStack projects? As much as possible, I'd like to avoid Quantum being different unless we really have a strong reason why it should be different.
A couple other comments: - my general feeling is that we should optimize version numbers for users of quantum (i.e., use CLI, write to client library), not developers of openstack (consume pre-release milestone). My feeling is that about the only guarantee we should give for compatibility in between releases is that if you get the latest from both master branches, it should work. - having some way to indicate the lack of backward compatibility either in CLI commands, or in the pythonic interface is valuable, as Mark mentioned. - I tend to see the third digit in a version number more being about stable release/bug fix than addition of minor features (which generally would just be rolled up into the next major release). Dan On Mon, Feb 4, 2013 at 4:22 PM, gong yong sheng <gong...@linux.vnet.ibm.com>wrote: > 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<https://launchpad.net/~quantum-core> >>> Post to : >>> quantum-core@lists.launchpad.**net<quantum-core@lists.launchpad.net> >>> Unsubscribe : >>> https://launchpad.net/~**quantum-core<https://launchpad.net/~quantum-core> >>> More help : >>> https://help.launchpad.net/**ListHelp<https://help.launchpad.net/ListHelp> >>> >> > > -- > Mailing list: > https://launchpad.net/~**quantum-core<https://launchpad.net/~quantum-core> > Post to : > quantum-core@lists.launchpad.**net<quantum-core@lists.launchpad.net> > Unsubscribe : > https://launchpad.net/~**quantum-core<https://launchpad.net/~quantum-core> > More help : > https://help.launchpad.net/**ListHelp<https://help.launchpad.net/ListHelp> > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dan Wendlandt Nicira, Inc: www.nicira.com twitter: danwendlandt ~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- 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
