Openblas: SONAME for 0.3.0 includes dev

[jakirkham]

When building the 0.3.0 release, noted that the SONAME of the libraries seems to include dev. For example, on Linux this is libopenblasp-r0.3.0.dev.so (we are building the pthreads version). Typically the .dev is not present.

Edit: Appears this line is the cause.

[martin-frbg]

Meh. Somehow I knew I was going to miss something (that would only be found out after the release), sorry. Opinions please - should 0.3.0 be re-released without the .dev, or should we aim for a 0.3.1 within the next two weeks with everything that gets found&fixed in between ?

[martin-frbg]

Plain make builds will have the same issue, as I did not change https://github.com/xianyi/OpenBLAS/blob/v0.3.0/Makefile.rule#L6 either

[jakirkham]

I think this is a minor issue. Would just try to fix it in 0.3.1. Mostly was trying to raise awareness.

[ViralBShah]

Yes, best to release 0.3.1.

[martin-frbg]

Set a "due date" of June 30 on the 0.3.1 milestone now.

[boegel]

@martin-frbg Any updates on 0.3.1? Is it still the plan to release 0.3.1 on June 30th? Is there an overview of changes that would be included somewhere?

[martin-frbg]

I have been tagging the more important things with the 0.3.1 milestone here: https://github.com/xianyi/OpenBLAS/milestone/20 - release date depends a bit on how well the new kids on the block behave with their work on threading and AVX512

[boegel]

@martin-frbg Do you think it makes sense to also tag merged PRs that will be included in 0.3.1 with the 0.3.1 milestone, so people have an auto-updating changelog to look at?

[martin-frbg]

Did not realize that with the branching to 0.3.0 (initiated by xianyi) we lost the convenient "x commits to develop since this release" on the releases pages (or rather, it keeps tracking from 0.2.20). My idea so far is to just merge all changes from develop into the 0.3.0 branch and release from there, so the list of changes would basically be all closed PRs since 1570 "Update release-0.3.0 branch to match develop" (or a bit more than one page in that overview)

[boegel]

@martin-frbg You can still tag the already merged PRs that are relevant for 0.3.1 (relative to 0.3.0), that would be quite useful imho...

Shouldn't be too much work for you via https://github.com/xianyi/OpenBLAS/pulls?q=is%3Apr+is%3Aclosed+sort%3Aupdated-desc, I assume...

[martin-frbg]

Great way to inflate the list of achievements with duplicates...

[boegel]

@martin-frbg Any delay expected for the planned 0.3.1 release?

[martin-frbg]

I am worried about #1641 of course - the avx512 dgemm issue from #1463 can be easily solved by just removing that new kernel again, but the speedup gained from the new thread setup code would be nice to have in 0.3.1

[ViralBShah]

@martin-frbg As always, we are happy to test the new release before tagging. Please let us know which commit to test.

cc @andreasnoack

[martin-frbg]

1625 seems to have caused grief for gonum (cannot create as many threads as they used to, but the circumstances are unclear as it is only known that their tests fail, but not exactly what they do internally)

[martin-frbg]

Fixed through #1657 and subsequent release of 0.3.1