[openstack-dev] [oslo] Oslo library versioning
Matt Joyce
matt.joyce at cloudscaling.com
Mon Nov 26 20:06:33 UTC 2012
For the record, I hate the current over all version scheme of OpenStack.
The complexities generated by making the code reliant on access to the git
repository it came from is problematic for many packaging scenarios. And
the cost to benefit seems unfairly biased towards code maintainers at the
moment.
But that's a different discussion.
On Mon, Nov 26, 2012 at 7:21 AM, Monty Taylor <mordred at inaugust.com> wrote:
>
>
> On 11/26/2012 06:38 AM, Doug Hellmann wrote:
>
> I can picture one option where we would version oslo libraries
>> separately, based on classic major.minor.patch format. We could make
>> "stable branches" based off major versions. That would be separate
>> from
>> the common development cycles and milestones, even if for planning
>> (and
>> summit) reasons you would still talk about "grizzly development
>> timeframe", and try to slow down towards the end of the cycle. We can
>> push all versions to PyPI and use ">=1.2.1 <2" style to solve the
>> dependency specification... and push to Launchpad in parallel to
>> provide
>> a sane, series-oriented view of the same deliverables.
>>
>> How does that sound ?
>>
>
> I agree with this. I am not worried about presenting multiple 'potentially
> confusing' versions of the oslo libraries on PyPI in the same way I am with
> client libraries, so I think this will work just fine.
>
> BTW - how's that upload-to-pypi jenkins job builder template coming along?
> :)
>
> Monty
>
>
> ______________________________**_________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.**org <OpenStack-dev at lists.openstack.org>
> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev<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/20121126/d3dc9526/attachment.html>
More information about the OpenStack-dev
mailing list