Open Stack

On Tue, 2013-03-05 at 10:29 -0500, Doug Hellmann wrote:
> 
> 
> On Tue, Mar 5, 2013 at 9:02 AM, Mark McLoughlin <markmc at redhat.com> wrote:
>         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"
> 
> 
> +1 to semantic versioning
> 
> 
> -0 to not cleaning up deprecated APIs

Thanks

>           - 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.
> 
> 
> And the major number?

If/when we ever remove deprecated APIs.

>         In practical terms, I'm proposing doing:
>         
>          -package = 'oslo-config'
>          -version = '2013.1'
>          +package = 'oslo.config'
>          +version = '1.1.0'
> 
> 
> Why not 1.0.0?

A weak, silly 2013.1.0-2012 approach :)

Cheers,
Mark.