[openstack-dev] [oslo] Oslo library versioning

Matt Joyce matt.joyce at cloudscaling.com
Fri Nov 30 21:24:51 UTC 2012


Maybe this isn't super helpful, but it has to be said.

I've been doing some packaging work for openstack lately.  And, that's lead
to me getting a bit testy on IRC.  Sorry for that.

A big part of my frustration comes from the way we version inside of
OpenStack core.

I'll break this down to two different concerns.


1.  First Concern - No standard.

We are ostensibly doing milestones for components, and independent yet
standardized versioning for clients.

Except for swift which is just kind of doing it's own thing not being a
part of OpenStack at all.

Now we're discussing possibly introducing a fourth versioning scheme.

It makes the automation of packaging that much more difficult if I have to
come up with new logic for every single component of openstack that has a
different versioning scheme.

Which leads me to the second point.

2.  Second Concern - .git derives our versioning

First, thank god for the versioninfo file.  Without it, cinderclient would
be unbuildable in certain situations.

It boils down to this logic:

from cinderclient/openstack/common/setup.py  ( which btw is common SOLELY
to cinderclient every other client does this logic in a different yet
standard fashion ).

def get_post_version(projectname):
    """Return a version which is equal to the tag that's on the current
    revision if there is one, or tag plus number of additional revisions
    if the current revision has no tag."""

    if os.path.isdir('.git'):
        version = _get_git_post_version()
        write_versioninfo(projectname, version)
        return version
    return open(os.path.join(projectname, 'versioninfo'),
'r').read().strip()

This basically says either grab the version from .git, or the versioninfo
file.  Except that generating the versioninfo file requires .git.

So I end up having to write logic to figure out release tagging and plug in
versioninfo files into the clients.  Which would be fine except right now
we have 3 different approaches to tagging repos in the project.

Please for the love of all that is happy and free in the world, don't
create a fourth.

-Matt


Hope this doesn't come off as aggressive or angry it's more exasperation.

On Fri, Nov 30, 2012 at 11:29 AM, Monty Taylor <mordred at inaugust.com> 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)
>
> 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.
>
> (we might be splitting hairs on this one)
>
> On 11/30/2012 11:07 AM, Joshua Harlow wrote:
> > Is there a versioning scheme that can be followed here?
> >
> > Stable releases on pypi have even numbers, odd numbers are unstable?
> >
> > Isn't something like that pretty common (?), then u can just upload
> > everything to pypi.
> >
> > Maybe that¹s another idea.
> >
> > On 11/30/12 5:45 AM, "Mark McLoughlin" <markmc at redhat.com> wrote:
> >
> >> On Mon, 2012-11-26 at 22:40 +0000, Mark McLoughlin wrote:
> >>> On Fri, 2012-11-23 at 11:55 +0100, Thierry Carrez wrote:
> >>>> There seem to be two options there: just push everything on the same
> >>>> PyPI module, or have multiple PyPI modules for each series. I'd say
> >>>> the latter looks worse.
> >>>
> >>> I don't really buy that unstable development releases of Oslo have to
> go
> >>> to PyPI in order for core projects to be able to consume them.
> >>>
> >>> pip supports http:// URLs of tarballs. Why not use that during
> >>> development?
> >>
> >> I'm kinda waiting for opinions on this :-)
> >>
> >> Cheers,
> >> Mark.
> >>
> >>
> >> _______________________________________________
> >> OpenStack-dev mailing list
> >> OpenStack-dev at lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121130/8d25df4a/attachment.html>


More information about the OpenStack-dev mailing list