Open Stack

Hey,

The thread on naming of namespace packages[1] and the discussion about
PEP426 on distutils-sig[2] have lead me to these conclusion:

  - Naming the package oslo.config is a better choice than oslo-config. 
    I don't think there's necessarily a standard for naming these 
    things but it seems more likely that period-separated will become
    more common than hyphen-separated (i.e. zope.interface vs
    oslo-config)

  - The date based 2013.1 version is likely to be disallowed by PEP426
    when it is ratified and we'll end up making the date based version
    a "private version" but 0.2013.1 would be the version on PyPI. Uggh.

  - I'm coming around to the idea of using semantic versioning (i.e. 
    x.y.z) and increasing the major number when removing any deprecated 
    APIs. That certainly is the trend expressed in PEP426 and on 
    distutils-sig. I'd be far more reluctant to actually remove 
    deprecated APIs, though, so this would change our policy from 
    "remove APIs after a year of deprecation" to "very rarely making 
    any incompatible changes to our APIs"

  - With semantic versioning, I figure we'd increase the micro number 
    when we do release from the stable branch and increase the minor 
    number with every coordinated OpenStack release.

In practical terms, I'm proposing doing:

 -package = 'oslo-config'
 -version = '2013.1'
 +package = 'oslo.config'
 +version = '1.1.0'

in oslo-config's setup.py

I know this is painful for packagers. In Fedora, I'll have to set an
"epoch" which packagers always hate doing. In Debian, it'll probably
mean the package name changing to python-oslo.config.

However, this is why we didn't publish directly to PyPI - we wanted the
opportunity to catch issues like this. So, I'm thinking we should just
go for it ASAP.

Thoughts?

Thanks,
Mark.

[1] - http://lists.openstack.org/pipermail/openstack-dev/2013-February/thread.html#6078
[2] - http://mail.python.org/pipermail/distutils-sig/2013-March/thread.html#20054