Open Stack

Completely agree with u, I've been thorough the package nightmare…

Maybe we can finally fix the whole thing with some consensus now that many people have been through the pain.

From: Matt Joyce <matt.joyce at cloudscaling.com<mailto:matt.joyce at cloudscaling.com>>
Reply-To: OpenStack Development Mailing List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: Friday, November 30, 2012 1:24 PM
To: OpenStack Development Mailing List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Subject: Re: [openstack-dev] [oslo] Oslo library versioning


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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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/8f7ffe43/attachment.html>