Ian Cordasco wrote: > On 7/10/15, 03:44, "Thierry Carrez" <thie...@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. 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) __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev