<br><br><div class="gmail_quote">On Tue, Mar 5, 2013 at 9:02 AM, Mark McLoughlin <span dir="ltr"><<a href="mailto:markmc@redhat.com" target="_blank">markmc@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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)</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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. </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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></blockquote><div><br></div><div>+1 to semantic versioning</div><div><br></div><div>-0 to not cleaning up deprecated APIs</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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></blockquote><div><br></div><div>And the major number?</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></blockquote><div><br></div><div>Why not 1.0.0?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
in oslo-config's setup.py<br>
<br>
I know this is painful for packagers. In Fedora, I'll have to set an<br>
"epoch" which packagers always hate doing. In Debian, it'll probably<br>
mean the package name changing to python-oslo.config.<br>
<br>
However, this is why we didn't publish directly to PyPI - we wanted the<br>
opportunity to catch issues like this. So, I'm thinking we should just<br>
go for it ASAP.<br>
<br>
Thoughts?<br>
<br>
Thanks,<br>
Mark.<br>
<br>
[1] - <a href="http://lists.openstack.org/pipermail/openstack-dev/2013-February/thread.html#6078" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2013-February/thread.html#6078</a><br>
[2] - <a href="http://mail.python.org/pipermail/distutils-sig/2013-March/thread.html#20054" target="_blank">http://mail.python.org/pipermail/distutils-sig/2013-March/thread.html#20054</a><br>
<br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br>