[openstack-dev] [all] Setting epoch in setup.cfg??

Ian Cordasco ian.cordasco at RACKSPACE.COM
Sat Jul 11 19:47:58 UTC 2015



On 7/10/15, 03:44, "Thierry Carrez" <thierry at openstack.org> wrote:

>Joshua Harlow wrote:
>> Hi all,
>> 
>> I was thinking about those who are packaging with venvs (and using the
>> version of a project in the venv file name); like what anvil[1] is now
>> capable of (and does this in the gate now[2]) or packaging via rpms
>> (which anvil also does) and they are going to be affected by the version
>> shrinkage that just recently happened this cycle.
>> 
>> Soooooo that got me around to thinking, why aren't all the projects
>> setting an epoch[3] in there setup.cfg (for the ones that had a version
>> shrinkage from 201X.Y to something small) to make it less painful for
>> all these people (and to make it obvious to those reading setup.cfg and
>> looking at the version number that a epoch change just happened)...
>> 
>> So I proposed https://review.openstack.org/#/c/200187/ (to cinder) but
>> didn't want to push something similar out everywhere before getting more
>> input, is there any reason we should not do that? Is there a better way
>> to do that? (Or something else I am missing?)
>
>As Robert posted on the review:
>
>a) pbr doesn't support epochs [yet]

Is there a bug for this? I'll be happy to tackle it.

>b) the release team specifically decided not to epoch things.
>
>Also you'll find that the various distros use different epoch values for
>the same software, because epoch are also used to cover local blunders
>in packaging and historical artifacts. That is why epochs should be
>local to each packaging system and specifying it upstream is imho
>counter-productive.

So, unpopular opinion time, but I think we restrict ourselves way too much
based on a false notion that the only people who consume OpenStack are
consuming it via downstream packages. Joshua has pointed out a very real
use case (deploying inside a virtual environment) and there are also cases
where people build from source and will be (attempting) to upgrade from
2015.1.x to 11.0.0 or 8.0.0. Even if people only use PyPI as a way of
determining version order, using epochs will be significantly better for
them. Perhaps I'm too late to the discussion, but it also appears no other
opinions were solicited for it, especially not from users or operators.

Specifically, I'd like to understand why using a feature of PEP 440 to
explicitly indicate a shift in version numbering is "counter-productive".
It seems like it would be very productive for people who aren't tightly
integrated into the development process.



More information about the OpenStack-dev mailing list