Open Stack

On Mon, 2012-12-03 at 11:09 +0100, Thierry Carrez wrote:
> Monty Taylor wrote:
> > Actually, if we have some snapshot releases which look like this:
> > 2012.2~G2~5 (for instance)
> > 
> > That get turned in to python versions that look like this:
> > 2012.2-alpha2.5  (for instance)
> 
> Yes, that was one of the options I considered, translating into
> something that PyPI actually supports. I tried to avoid that because it
> makes us use two different-looking version numbers to represent the same
> thing (2013.1~G2 = 2013.2-alpha2), but since for oslo libraries we'll
> have to push intermediary versions between milestones anyway... it's no
> longer a 1:1 match. So I guess it's not such a big deal.

I don't think we can use PyPI for development/apha/milestone releases
while PyPI has no way for us to ensure that "pip install oslo-config"
won't install a development snapshot.

i.e. PyPI has only one stream and IMHO it only makes sense for that to
be our stable stream, not our development stream.

> > Then I don't understand why we couldn't upload snapshots and real
> > releases to pypi - and then have nova do:
> > oslo-foo>=2012.2,<=2013.1
> > In its pip-requires.
> 
> That's what I proposed higher in the thread, but Mark replied:
> 
> > I really, really hate version caps like that :)
> 
> So I suspect there is no consensus yet about that...

Right :)

  http://lists.openstack.org/pipermail/openstack-dev/2012-November/003349.html

A <=2013.1 cap is simply inaccurate and misleading.

Say we ended up with this in the Grizzly release:

  glance: oslo-config>=2013.1,<2013.2
  nova: oslo-config>=2013.1,<2013.2

and then the H release comes out:

  glance: oslo-config>=2013.2,<2014.1
  nova: oslo-config>=2013.2,<2014.1

You now cannot update Glance to the H release on a single system without
breaking the requirement conditions of the installed Nova Grizzly
package.

And a big reason for wanting stable APIs in Oslo library packages is to
allow those types of situations.

Cheers,
Mark.