<br>Maybe this isn't super helpful, but it has to be said.<br><br>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.<br><br>A big part of my frustration comes from the way we version inside of OpenStack core.<br>
<br>I'll break this down to two different concerns.<br><br><br>1.  First Concern - No standard.<br><br>We are ostensibly doing milestones for components, and independent yet standardized versioning for clients.<br><br>
Except for swift which is just kind of doing it's own thing not being a part of OpenStack at all.<br><br>Now we're discussing possibly introducing a fourth versioning scheme. <br><br>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.<br>
<br>Which leads me to the second point.<br><br>2.  Second Concern - .git derives our versioning<br><br>First, thank god for the versioninfo file.  Without it, cinderclient would be unbuildable in certain situations.<br><br>
It boils down to this logic:<br><br>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 ).<br><br>def get_post_version(projectname):<br>
    """Return a version which is equal to the tag that's on the current<br>    revision if there is one, or tag plus number of additional revisions<br>    if the current revision has no tag."""<br>
<br>    if os.path.isdir('.git'):<br>        version = _get_git_post_version()<br>        write_versioninfo(projectname, version)<br>        return version<br>    return open(os.path.join(projectname, 'versioninfo'), 'r').read().strip()<br>
<br>This basically says either grab the version from .git, or the versioninfo file.  Except that generating the versioninfo file requires .git.<br><br>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.<br>
<br>Please for the love of all that is happy and free in the world, don't create a fourth.<br><br>-Matt<br><br><br>Hope this doesn't come off as aggressive or angry it's more exasperation.  <br><br><div class="gmail_quote">
On Fri, Nov 30, 2012 at 11:29 AM, Monty Taylor <span dir="ltr"><<a href="mailto:mordred@inaugust.com" target="_blank">mordred@inaugust.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Actually, if we have some snapshot releases which look like this:<br>
<br>
2012.2~G2~5 (for instance)<br>
<br>
That get turned in to python versions that look like this:<br>
<br>
2012.2-alpha2.5  (for instance)<br>
<br>
Then I don't understand why we couldn't upload snapshots and real<br>
releases to pypi - and then have nova do:<br>
<br>
oslo-foo>=2012.2,<=2013.1<br>
<br>
In its pip-requires.<br>
<br>
(we might be splitting hairs on this one)<br>
<div class="HOEnZb"><div class="h5"><br>
On 11/30/2012 11:07 AM, Joshua Harlow wrote:<br>
> Is there a versioning scheme that can be followed here?<br>
><br>
> Stable releases on pypi have even numbers, odd numbers are unstable?<br>
><br>
> Isn't something like that pretty common (?), then u can just upload<br>
> everything to pypi.<br>
><br>
> Maybe that¹s another idea.<br>
><br>
> On 11/30/12 5:45 AM, "Mark McLoughlin" <<a href="mailto:markmc@redhat.com">markmc@redhat.com</a>> wrote:<br>
><br>
>> On Mon, 2012-11-26 at 22:40 +0000, Mark McLoughlin wrote:<br>
>>> On Fri, 2012-11-23 at 11:55 +0100, Thierry Carrez wrote:<br>
>>>> There seem to be two options there: just push everything on the same<br>
>>>> PyPI module, or have multiple PyPI modules for each series. I'd say<br>
>>>> the latter looks worse.<br>
>>><br>
>>> I don't really buy that unstable development releases of Oslo have to go<br>
>>> to PyPI in order for core projects to be able to consume them.<br>
>>><br>
>>> pip supports http:// URLs of tarballs. Why not use that during<br>
>>> development?<br>
>><br>
>> I'm kinda waiting for opinions on this :-)<br>
>><br>
>> Cheers,<br>
>> Mark.<br>
>><br>
>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br>