[openstack-dev] Could we please use 1.4.1 for oslo.messaging *now*? (was: Oslo final releases ready)

Doug Hellmann doug at doughellmann.com
Tue Sep 23 15:17:31 UTC 2014


On Sep 23, 2014, at 4:35 AM, Thomas Goirand <zigo at debian.org> wrote:

> On 09/18/2014 10:04 PM, Doug Hellmann wrote:
>> All of the final releases for the Oslo libraries for the Juno cycle are available on PyPI. I’m working on a couple of patches to the global requirements list to update the baseline in the applications. In all cases, the final release is a second tag on a previously released version.
>> 
>> - oslo.config - 1.4.0 (same as 1.4.0.0a5)
>> - oslo.db - 1.0.0 (same as 0.5.0)
>> - oslo.i18n - 1.0.0 (same as 0.4.0)
>> - oslo.messaging - 1.4.0 (same as 1.4.0.0a5)
>> - oslo.rootwrap - 1.3.0 (same as 1.3.0.0a3)
>> - oslo.serialization - 1.0.0 (same as 0.3.0)
>> - oslosphinx - 2.2.0 (same as 2.2.0.0a3)
>> - oslotest - 1.1.0 (same as 1.1.0.0a2)
>> - oslo.utils - 1.0.0 (same as 0.3.0)
>> - cliff - 1.7.0 (previously tagged, so not a new release)
>> - stevedore - 1.0.0 (same as 1.0.0.0a2)
>> 
>> Congratulations and *Thank You* to the Oslo team for doing an amazing job with graduations this cycle!
>> 
>> Doug
> 
> Doug,
> 
> Here in Debian, I have a *huge* mess with versionning with oslo.messaging.
> 
> tl;dr: Because of that version number mess, please add a tag 1.4.1 to
> oslo.messaging now and use it everywhere instead of 1.4.0.

I’ve re-tagged 1.4.0 as 1.4.1 to give you a clean thing to package.

We shouldn’t need to update our requirements list in OpenStack, yet, because 1.4.1 >= 1.4.0, but you can use 1.4.1 for the Debian requirements.

Doug

> 
> Longer version:
> 
> What happened is that Chuck released a wrong version of Keystone (eg:
> the trunk rather than the stable branch). Therefore, I uploaded a
> version 1.4.0 beta version of olso.messaging in Debian Unstable/Jessie,
> because I thought the Icehouse version of Keystone needed it. (Sid /
> Jessie is supposed to keep Icehouse stuff only.)
> 
> That would have been about fine, if only I didn't upgraded
> oslo.messaging to the last version in Sid, because I didn't want to keep
> a beta release in Jessie. Though this last version depends on
> oslo.config 1.4.0.0~a5, then probably even more.
> 
> So I reverted the 1.4.0.0 upload in Debian Sid, by uploading version
> 1.4.0.0+really+1.3.1, which as its name may suggest, really is a 1.3.1
> version (I did that to avoid having an EPOC and need to re-upload
> updates of all reverse dependencies of oslo.messaging). That's fine,
> we're covered for Sid/Jessie.
> 
> But then, the Debian Experimental version of oslo.messaging is lower
> than the one in Sid/Jessie, so I have breakage there.
> 
> If we declare a new 1.4.1, and have this fixed in our
> global-requirements.txt, then everything goes back in order for me, I
> get back on my feets. Otherwise, I'll have to deal with this, and make
> fake version numbers which will not match anything real released by
> OpenStack, which may lead to even more mistakes.
> 
> So, could you please at least:
> - add a "git tag 1.4.1" to oslo.messaging right now, matching 1.4.0
> 
> This will make sure that nobody will use 1.4.1 again, and that I'm fine
> using this version number in Debian Experimental, which will be higher
> than the one in Sid.
> 
> And then, optionally, it would help me if you could (but I can leave
> without it):
> - Use 1.4.1 for oslo.messaging in global-requirements.txt
> - Have every project that needs 1.4.0 bump to 1.4.1 as well
> 
> This would be a lot less work than for me to declare an EPOC in the
> oslo.messaging package, and fix all reverse dependencies. The affected
> packages for Juno for me are:
> - ceilometer
> - cinder
> - designate
> - glance
> - heat
> - ironic
> - keystone
> - neutron
> - nova
> - oslo-config
> - oslo.rootwrap
> - oslo.i18n
> - python-pycadf
> 
> I'd have to upload updates for all of them even if we use 1.4.1 instead
> of using an EPOC (eg: 1:1.4.0), but that's still much better for me to
> use 1.4.1 than an EPOC. EPOC are ugly (because not visible in file
> names) and confusing (it's easy to forget them), and non-reversible, so
> I'd like to avoid it if possible.
> 
> I'm sorry for the mess and added work.
> Cheers,
> 
> Thomas Goirand (zigo)
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




More information about the OpenStack-dev mailing list