other projects have no version plan for clients. They have just one dev
series.
For quantum client, we have created our series and milestone, if we
don't bump versions according to it,
I am afraid we will create confusion.
our current milestone is 3.0.0. If our pypi's version for it is 2.2 or
something else, who knows what is what?
On 02/06/2013 05:22 AM, Dan Wendlandt wrote:
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 <mailto: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
<mailto: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/%7Equantum-core>
Post to : quantum-core@lists.launchpad.net
<mailto:quantum-core@lists.launchpad.net>
Unsubscribe : https://launchpad.net/~quantum-core
<https://launchpad.net/%7Equantum-core>
More help : https://help.launchpad.net/ListHelp
--
Mailing list: https://launchpad.net/~quantum-core
<https://launchpad.net/%7Equantum-core>
Post to : quantum-core@lists.launchpad.net
<mailto:quantum-core@lists.launchpad.net>
Unsubscribe : https://launchpad.net/~quantum-core
<https://launchpad.net/%7Equantum-core>
More help : https://help.launchpad.net/ListHelp
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com <http://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
