Let's tag 0.7.0

[ViralBShah]

Should we tag the current master as 0.6.1?

[ararslan]

For reference, the commits from 0.6.0 to current master: v0.6.0...master

[ginggs]

I ran test builds of current HEAD on Ubuntu 20.04. No problems on amd64, arm64 and ppc64el.

Two symbols were dropped on armhf (32-bit ARM):
fdiml@Base and scalblnl@Base
Is that expected?
https://launchpadlibrarian.net/454770434/buildlog_ubuntu-focal-armhf.openlibm_0.6.1-0ubuntu1~ppa1_BUILDING.txt.gz

There were several symbols added and removed on s390x.
https://launchpadlibrarian.net/454770344/buildlog_ubuntu-focal-s390x.openlibm_0.6.1-0ubuntu1~ppa1_BUILDING.txt.gz

Should the SONAME be bumped because of these?

[ViralBShah]

We should look into arm. Not sure what's happening on s390 - but someone who is interested in that architecture should take a look - perhaps @sharkcz

[sharkcz]

s390x is a new port for 0.6.1, so there shouldn't be any compatibility issues

[ginggs]

My mistake! Somehow I used the debian packaging files from 0.6.0+dfsg-1, instead of 0.6.0+dfsg-2 (which cherry-picked the s390x port).

There are still two dropped symbols on 32-bit arm:
https://launchpad.net/~ginggs/+archive/ubuntu/testing/+build/18226111/+files/buildlog_ubuntu-focal-armhf.openlibm_0.6.1-0ubuntu1~ppa2_BUILDING.txt.gz

...but there are no problems on s390x.

[ViralBShah]

Those are dropped on arm because we are disabling OPENLIBM_LONG_DOUBLE on arm, which doesn't build. I verified it worked on arm on v0.6.0 because scalblnl was not protected by OPENLIBM_LONG_DOUBLE until it was fixed for wasm32 in 72f33a3. Same for fdiml

[ViralBShah]

I think we should tag as v0.7.0 as a result of the above. Thanks @ginggs.

[ViralBShah]

Also noting the SONAME bump to 3.0 in 5efed30