Ian Cordasco wrote:
On 7/10/15, 03:44, "Thierry Carrez"<[email protected]> 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.
Not IMHO unpopular, in fact I agree with it (but maybe that means I'm
unpopular to, ha). IMHO the epoch values 'reasons' as Thierry specified
are exactly what we are trying to do, openstack had a 'cover local
blunders in packaging and historical artifacts' *moment* by having date
based versions and changing it 4+ years into the game and now it needs
to correctly handle that 'blunder'.
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.
I'd like to know that to; and it IMHO raises another question, why did
we go about changing all the versions without epoch support in the first
place? Shouldn't we make sure PBR (or other tool) has epoch support,
then change the version numbers, not the other way around? (I do not
question the reasoning to change the version numbers themselves, I get
that, just the ordering of how it was done...)
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
