<br><br><div class="gmail_quote">On Fri, Nov 23, 2012 at 5:55 AM, Thierry Carrez <span dir="ltr"><<a href="mailto:thierry@openstack.org" target="_blank">thierry@openstack.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">Monty Taylor wrote:<br>
> On 11/22/2012 09:44 AM, Mark McLoughlin wrote:<br>
>> On Tue, 2012-11-13 at 15:19 +0100, Thierry Carrez wrote:<br>
</div><div class="im">>>>> Should Oslo library packages be part of the co-ordinated release<br>
>>>> schedule along with the core services? Or should they follow their<br>
>>>> own (ad-hoc?) release schedule?<br>
>>><br>
>>> Adding another question: should all oslo libraries share the same<br>
>>> versioning ? i.e. should oslo.config version be updated when oslo.rpc<br>
>>> needs to be released ?<br>
>><br>
>> No, it's not required, but I think there's some value in a checkpoint<br>
>> release of all the libraries in the same family using the same version.<br>
>> It would just make it easier for folks to understand which versions<br>
>> belong together, given they will be dependent on each other.<br>
<br>
</div>IMHO that would add a lot of versioning constraints for little gain. We<br>
can describe oslo interdependencies using the same mechanism as other<br>
libraries.<br>
<div class="im"><br>
>>>> Which versions get released to PyPi? Should we have a stable branch<br>
>>>> of these libraries with stable releases?<br>
>>><br>
>>> That's the crux of the issue. We have two valid models:<br>
>>><br>
>>> 1- Integrated with common release, using common versioning, not using<br>
>>> PyPI, supporting stable/* branches and stable point releases<br>
>>><br>
>>> 2- Ad-hoc versioning, ignoring the common cycle, using PyPI (which makes<br>
>>> stable point releases look weird)<br>
>>><br>
>>> I'm not sure there is a middle solution. I guess we /could/ support<br>
>>> stable branches and stable point releases in solution (2), despite<br>
>>> PyPI's lack of good support for it... but then I'd prefer if those<br>
>>> stable branches were disconnected from the common release cycle (i.e.<br>
>>> the stable series would be "1.x" and not "folsom") so that we don't tie<br>
>>> a lot of different weird version numbers to a given series.<br>
><br>
> Let's assume we'll figure out the PyPI question, even if it looks weird.<br>
> There are examples of other projects using multiple release streams to<br>
> pypi we can examine (this has a different consumption usecase than the<br>
> client libs, so I think my objections to stable releases there doesn't<br>
> apply here)<br>
<br>
</div>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 the<br>
latter looks worse. For the former, I suspect you can specify ">=1.2.1<br>
<2" as far as dependencies are concerned.<br>
<br>
What's missing then is a sane view of the tree of available versions,<br>
but if we upload the same tarballs to PyPI and Launchpad, we can present<br>
a series-oriented view of the tree of versions that makes a lot more<br>
sense. We did not really do that (yet) for client libraries because they<br>
use a single series, so the gain of also uploading to LP is not as<br>
obvious. Oh and, I'm slacking and did not write that auto-upload-to-LP<br>
script to hook into CI yet.<br>
<div class="im"><br>
>> Well, to add two more questions:<br>
>><br>
>>    * When do we commit to compatibility around a new API in Oslo? When<br>
>>      it gets committed, when it gets released or when we release an<br>
>>      officially "API frozen" version?<br>
><br>
> I vote for when it gets released.<br>
><br>
>>    * How do other OpenStack projects consume Oslo libraries during<br>
>>      development? e.g. can you put a git URL into pip-requires, or must<br>
>>      you have a pypi release version there?<br>
>><br>
>> You could say e.g. new APIs are committed to when they're released to<br>
>> pypi and OpenStack projects can only consume new APIs once they've been<br>
>> released to pypi.<br>
><br>
> Yes please. We have done cross-project git-url consumption before. It's<br>
> a nightmare (largely because although the python toolchain tempts us<br>
> into thinking this will work, it doesn't actually fully work.<br>
><br>
>> But that could result us doing library releases too often, integration<br>
>> with other projects being too slow or us only realizing we've made<br>
>> drastic API design mistakes after committing to the new API.<br>
><br>
> Honestly, I think you have a slightly easier time of it than the client<br>
> lib folks in terms of API commitment - since you know who your consumers<br>
> are, and you can actually check around to see if anyone is using an old<br>
> API. It's not too terrible - how about we try it that way for a bit and<br>
> see if there are actual logistical problems?<br>
<br>
</div>That's a lot of questions, let's try to explore options and see how dumb<br>
they sound...<br>
<br>
I can picture one option where we would version oslo libraries<br>
separately, based on classic major.minor.patch format. We could make<br>
"stable branches" based off major versions. That would be separate from<br>
the common development cycles and milestones, even if for planning (and<br>
summit) reasons you would still talk about "grizzly development<br>
timeframe", and try to slow down towards the end of the cycle. We can<br>
push all versions to PyPI and use ">=1.2.1 <2" style to solve the<br>
dependency specification... and push to Launchpad in parallel to provide<br>
a sane, series-oriented view of the same deliverables.<br>
<br>
How does that sound ?<br></blockquote><div><br></div><div>+1</div><div><br></div><div>Doug</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im HOEnZb"><br>
--<br>
Thierry Carrez (ttx)<br>
Release Manager, OpenStack<br>
<br>
</div><div class="HOEnZb"><div class="h5">_______________________________________________<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>