<br><br>On Tuesday, March 5, 2013, Mark McLoughlin  wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, 2013-03-05 at 10:29 -0500, Doug Hellmann wrote:<br>

><br>
><br>
> On Tue, Mar 5, 2013 at 9:02 AM, Mark McLoughlin <<a href="javascript:;" onclick="_e(event, 'cvml', 'markmc@redhat.com')">markmc@redhat.com</a>> wrote:<br>
>         Hey,<br>
><br>
>         The thread on naming of namespace packages[1] and the discussion about<br>
>         PEP426 on distutils-sig[2] have lead me to these conclusion:<br>
><br>
>           - Naming the package oslo.config is a better choice than oslo-config.<br>
>             I don't think there's necessarily a standard for naming these<br>
>             things but it seems more likely that period-separated will become<br>
>             more common than hyphen-separated (i.e. zope.interface vs<br>
>             oslo-config)<br>
><br>
>           - The date based 2013.1 version is likely to be disallowed by PEP426<br>
>             when it is ratified and we'll end up making the date based version<br>
>             a "private version" but 0.2013.1 would be the version on PyPI. Uggh.<br>
><br>
>           - I'm coming around to the idea of using semantic versioning (i.e.<br>
>             x.y.z) and increasing the major number when removing any deprecated<br>
>             APIs. That certainly is the trend expressed in PEP426 and on<br>
>             distutils-sig. I'd be far more reluctant to actually remove<br>
>             deprecated APIs, though, so this would change our policy from<br>
>             "remove APIs after a year of deprecation" to "very rarely making<br>
>             any incompatible changes to our APIs"<br>
><br>
><br>
> +1 to semantic versioning<br>
><br>
><br>
> -0 to not cleaning up deprecated APIs<br>
<br>
Thanks<br>
<br>
>           - With semantic versioning, I figure we'd increase the micro number<br>
>             when we do release from the stable branch and increase the minor<br>
>             number with every coordinated OpenStack release.<br>
><br>
><br>
> And the major number?<br>
<br>
If/when we ever remove deprecated APIs.</blockquote><div><br></div><div>OK</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
>         In practical terms, I'm proposing doing:<br>
><br>
>          -package = 'oslo-config'<br>
>          -version = '2013.1'<br>
>          +package = 'oslo.config'<br>
>          +version = '1.1.0'<br>
><br>
><br>
> Why not 1.0.0?<br>
<br>
A weak, silly 2013.1.0-2012 approach :)</blockquote><div><br></div><div>Heh, got it. </div><div><br></div><div>Doug<span></span></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
Cheers,<br>
Mark.<br>
<br>
<br>
</blockquote>