Setup Github Releases

[solvingj]

When pulling in sources to build and package this library, the ideal case is for the library authors to use Github releases with periodic versioned releases. Currently we're pulling from Master and pinning to commits, but that is sub-optimal. It doesn't even need to be a 1.0 release, it could be some 0.1.0 pre-release.

[darix]

+1 for doing releases

[daanx]

Ah, great idea. Are you suggesting I should do an initial release already soon (like next week)? (as that will help maintainers)?

[solvingj]

Yes, it is desirable for consumers as packagers can start putting "official" version numbers on packages. It's trivial in the github UI to create releases manually, and mark them as pre-releases. As you start to figure out how you want to handle the release cycle "automatically", Azure Pipelines can do new minor/major releases based on git events.

Of note, the file mimalloc-config-version.cmake currently features version number ""1.0". Moving forward I would suggest keeping this version field in sync with the Github releases. I would also suggest including a patch number for full semantic versioning (3 digits).

[dscho]

You could even set up an Azure Pipeline to do that (triggered manually, of course), using https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/utility/github-release

[dscho]

Isn't this done now? We're already at v1.0.5...

[daanx]

.. :-) Ah, there were so many important issues fixed in the recent week that I didn't feel confident to put out the first real release just yet. However, I think it is getting there with v1.0.5 -- I hope to put out the first release by the end of this week.

I will study the link you gave to see if I can make it easy using the Azure pipelines, and perhaps even supply binaries for Windows. Thanks!

[zerodefect]

Some accompanying release notes would be terrific. This saves devs considerable time from having to go through commits to see the big changes.

[alexmyczko]

Could these be dropped from the releases please?
W: mimalloc source: source-contains-prebuilt-windows-binary bin/mimalloc-redirect.dll
W: mimalloc source: source-contains-prebuilt-windows-binary bin/mimalloc-redirect32.dll

[alexmyczko]

lintian also complains about SONAME not set:

N: Processing binary package mimalloc (version 1.0.8-1, arch amd64) ...
E: mimalloc: sharedobject-in-library-directory-missing-soname usr/lib/libmimalloc-none.so
N: 
N:    A shared object was identified in a library directory (a directory in
N:    the standard linker path) which doesn't have a SONAME. This is usually
N:    an error.
N:    
N:    SONAMEs are set with something like gcc -Wl,-soname,libfoo.so.0, where 0
N:    is the major version of the library. If your package uses libtool, then
N:    libtool invoked with the right options should be doing this.
N:    
N:    To view the SONAME of a shared library, run readelf -d on the shared
N:    library and look for the tag of type SONAME.
N:    
N:    Severity: important, Certainty: possible
N:    
N:    Check: shared-libs, Type: binary, udeb
N: 
N: Finished processing group mimalloc/1.0.8-1

[dscho]

Could these be dropped from the releases please?
W: mimalloc source: source-contains-prebuilt-windows-binary bin/mimalloc-redirect.dll
W: mimalloc source: source-contains-prebuilt-windows-binary bin/mimalloc-redirect32.dll

Why?

[alexmyczko]

@dscho because it's a source tarball release? feel free to make additional releases (binary ones) with specific targets like mimalloc-1.0.8-windows if you want them?

[solvingj]

yes, the de-facto zip/tar.gz release should only ever contain the sources. There are dll's in the bin directory which should be removed moving forward.

[daanx]

Ah, the new dll's are used on Windows only to redirect the C runtime malloc to use mimalloc.
The current "release" are generated by the Azure pipeline infrastructure -- I am not sure how to modify that so it adds those dll's for the windows release but not for the others.

[daanx]

The SONAME not set warning is interesting. I see it is turned off in the cmake build to prevent CMake from adding a .1 version postfix to the .so name since we already version it by putting the whole install into a versioned directory, (e.g /usr/local/lib/mimalloc-1.0/libmimalloc-debug.so) so everything including headers etc is versioned (e.g /usr/local/lib/mimalloc-1.0/include/mimalloc.h).

Not sure why it is bad to leave out the internal soname from the .so though?

[dscho]

because it's a source tarball release?

@alexmyczko thank you, this was the explanation I was missing.

[solvingj]

I am not sure how to modify that so it adds those dll's for the windows release but not for the others.

When someone does get around to changing the AZP config for this, I would suggest providing a single zip of pure sourcs, and then separate zips for each precompiled binary you want to release.

Regarding SONAME:
The custom versioning and layout strategy in place right now is going to be at odds with various tools as more and more people try to integrate mimalloc In mature ecosystems (rpm/apt/brew/etc). SONAME isn’t cosmetic in these ecosystems, it serves an important purpose that will become very relevant to Linux packagers as mimalloc continues to evolve. Some changes will break ABI compatibility and some won’t, and the SONAME is the standard mechanism for controlling linking behavior in a sane way for each scenario. Having the version hardcoded in the directory name and omitting SONAME will likely cause difficulty in most upgrade scenarios when v1.1, and 2.0 are released.

[dscho]

When someone does get around to changing the AZP config for this, I would suggest providing a single zip of pure sourcs, and then separate zips for each precompiled binary you want to release.

Why not be that someone, @solvingj?

[alexmyczko]

Thanks, can we have a tarball release of that or have it in master branch?