Open Stack

On 2019-03-26 10:46:43 -0700 (-0700), Tim Burke wrote:
> On Tue, 2019-03-26 at 14:31 +0000, Jeremy Stanley wrote:
> > On 2019-03-25 10:55:29 -0500 (-0500), Sean McGinnis wrote:
> > [...]
> > > I would like to have cinder 2012.2 removed from PyPi
> > [...]
> > 
> > I have done this now. We've been removing any old date-based
> > versions from PyPI as we come across them, to avoid the confusion
> > you've noted. Cinder 2012.2 release candidates and point releases
> > are still available at https://tarballs.openstack.org/cinder/ as
> > well as from tags in its Git repository.
> 
> I suppose it's a little late now, but isn't this exactly the use-case
> for the epoch component in PEP-440 [1]? There's no fixing the existing
> tags, but we could at least fix it going forward...
> 
> [1] https://www.python.org/dev/peps/pep-0440/#adding-version-epochs

You say this as if you think we would have completely missed that
PEP 440 had a notion of epochs when we evaluated our various options
for the coordinated SemVer transition some 4-5 years ago. In fact,
you'll see the section immediately before the one you linked
actually refers explicitly to our (at that time) impending
transition away from date-based versions. ;)

The main reason we opted not to add epochs is that there were but a
scant handful of packages we'd published to PyPI with date-based
versions, mostly by accident and almost none of which would have
actually worked if you tried to `pip install` them. It *did* create
some disruption[*] for OSAD's Kilo to Liberty upgrades on
source-based installations, but as they were already in control of
what versions their playbooks installed they were able to work
around it by forcing a "downgrade" in the command used to install
the packages they built. Distro package maintainers were going to
have to add their own epochs anyway at the point our versions rolled
"backwards," and not doing so in our Python packages avoided a
number of sticky problems (epochs wind up embedded in your sdist
filenames, PBR would have needed a new feature to support having the
epoch-prepended version number not match the corresponding Git tag,
distros may have already added their own epochs on some packages so
embedding ours could lead to confusion when they didn't match...).

Part of the disconnect is that PEP 440 epochs treat sdist artifacts
as built packages (same could be said for its support for local
version identifiers and post releases), while we've considered them
to be our source tarballs. As such, we want the sdist versions to
match those we've tagged in Git. This approach is made possible
primarily due to the fact that our projects are "pure python" and
also because we don't vendor any content from other projects into
our packages, so there is little need to distinguish the versions of
our sdist (or even wheel) builds from the source code they directly
bundle.

[*] http://lists.openstack.org/pipermail/openstack-dev/2015-July/071034.html
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190326/efda8b75/attachment.sig>