Bruno Haible <br...@clisp.org> writes: >> Usually, I bump the required version when there is any change in the >> dependent modules since the last release, using the scripts: >> >> https://git.savannah.gnu.org/gitweb/?p=libunistring.git;a=blob;f=Admin/README.update;h=76c9925c2cb63b86b6bbdc62037706c95ac399ed;hb=HEAD#l45 >> >> However, I don't see such changes since 0.9.8. Could you elaborate why >> this change is appropriate, for future improvements of the release >> process? > > Between 0.9.8 and 0.9.9 we did not change anything, because the only > relevant change was the multithread-safety fix of 'malloca'. Hmm, I don't > know whether a malloca() from before the change and a freea() from after > the change (or vice versa) (one coming from the libunistring.so, one > from the executable) will work well together... > > Between 0.9.9 and 0.9.10 we added a couple of modules to libunistring, > that were already included in gnulib. > Why the change is needed? When a program requests a module such as > 'unicase/u8-prefix-context' and the module description has > > gl_LIBUNISTRING_MODULE([0.9.8], [unicase/u8-prefix-context]) > > the autoconfiguration (when it finds a preinstalled libunistring > version 0.9.8 or 0.9.9) will not compile the module locally for the > executable, but reference the installed libunistring - thus leading > to a link error. Whereas with > > gl_LIBUNISTRING_MODULE([0.9.10], [unicase/u8-prefix-context]) > > the autoconfiguration will compile the module locally - thus filling > the "hole" in the installed libunistring.
So, is my understanding correct that this only affects unreleased version of libunistring (0.9.10 is not released)? I was confused because you urged a new release for this: https://lists.gnu.org/archive/html/bug-libunistring/2018-04/msg00003.html And if it is the case, my answer again would be "not this time", because the fix in the Gnulib git should be sufficient. Regards, -- Daiki Ueno
