Update submodule from v1.6.7 to v2.0.0
errantmind opened this issue · comments
Hello, thanks for maintaining these bindings. I was wondering if you can update your submodule of mimalloc from v1.6.7 to v2.0.0 to take advantage of the improvements.
It's currently pointed at master, which has the same code as v2.0.0 (the only patch it doesn't have that the v2.0.0 tg has is a change to the cmake build script, which we no longer use).
Are you sure? It looks like v2.0.0 comes from the dev-slice branch which is 200 commits ahead of Master
@errantmind appears to be correct:
master: latest stable release.
dev: development branch for mimalloc v1.
dev-slice: development branch for mimalloc v2 with a new algorithm for managing internal mimalloc pages.
The currect cc build script also only works for master and dev while dev-slice, which is being referred to here as V2, does not. I think it would be better to use feature flags for development branches though rather than use dev over the stable release.
mimalloc 2.0.0 is now stable. We can just upgrade the dependency rather than make a feature.
It looks like the submodule is pointed at 2.0.6 already.
My bad, didn't see that. Can we close this issue and the related PRs, in that case?
Hey, I'm on mobile right now so my ability to look into this is limited.. but it looks like the submodule is pointed at master which is not the 2.0 (dev-slice) branch upstream. Can anyone verify?
The sub-module currently links to https://github.com/microsoft/mimalloc/tree/f2712f4a8f038a7fb4df2790f4c3b7e3ed9e219b which is the exact same hash as the tag v2.0.6, so the current version of mimalloc_rust links to the latest v2 tagged version, which is nice 😄 .
Though, i still think that it could be useful for some to be able to switch between versions if they need to. Since there arn't that much differences between the two, and it keeps working, it could be useful for some to be able to switch between v1 and v2 if they want/need to. But also use the latest version of either the dev or dev-slice branch. Maybe it's even an idea that people can select the version by tags and those tags can be set via en ENV variable as is done for many crates which bind to external libraries.
If not set, it will just use the defaults, else it will try to pull that tag/hash and use that, which is all up-to the developer who is changing that.