Open Stack

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

>Ian Cordasco wrote:
>> On 7/10/15, 03:44, "Thierry Carrez" <thierry at openstack.org> wrote:
>>> 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.
>
>By "counter-productive", I meant: likely to generate more confusion than
>clarity. If you provide an epoch in the version and it doesn't match
>downstream packagers ones, it's hard to rely on it.

I see what you mean now. The thing is that for Debian/Fedora the epoch
syntax is different from PEP 440

For them it's

[distro-epoch]:[upstream-version][otherstuff]

PEP 440 epochs are separated by a !, so let's say $(distro) has an epoch
value of "1" and we choose "2", for glance the version would look ugly but
would be:

1:2!11.0.0

>That said, I can see your point: people who consume from pip would like
>to have epochs too, epoch-sanitized versioning should not be reserved to
>distros.
>
>What I want to avoid is releasing nova-2!12.0.0.0.tar.gz tarballs,
>because that would be ugly (and confusing, with distros all having their
>own idea of an epoch set as well). But I don't mind including an epoch=
>parameter in setup.cfg if that makes pip happier.
>
>Could you detail what your preferred system would look like ?
>
>-- 
>Thierry Carrez (ttx)

So as Joshua already pointed out, epochs exist in PEP 440 for exactly our
situation. In fact, the PEP specifically calls out:

> For example, if a project is using date based versions like 2014.04 and
>would like to switch to semantic versions like
     
> 1.0, then the new releases would be identified as older than the date
>based releases when using the normal sorting scheme


I also want to point out that epochs are not a one-and-done situation
before proposing what I'm about to propose. Once we start using them, for
the ordering to be as we intend, we have to continue using them.

So I know that some projects have been through more than one versioning
scheme already. For them, I think the epoch value should be: 2. For the
rest I would argue that the value should be 1.

For example, Nova's tags have 0.9.0 as the earliest tagged version and
2011.1 as the one after that. So Nova's version would be 2!12.0.0. Glance
has started with 2011.3 (to the best of my knowledge) so that would be
1!11.0.0.

I agree this probably might be confusing, so I'm fine with everything
using a single epoch value. (All using 1 or all using 2 or whatever we
choose.)

That said, I think we should keep our epoch values simple to keep them
standard (e.g., a numeric value, not something like nova-2). Further, I
think you're nudging towards epoch's being something that pbr adds to the
version when it's installed by pip. That seems reasonable, but I think we
will end up confusing people if they see 1!11.0.0 of Glance installed when
they used the 11.0.0 tag from Glance. Does that make sense? I think the
tags should include the epoch. Does anyone have a good reason for not
including the epoch in the tag?

Cheers,
Ian