bump libgit2 to 1.5.0 #858
Conversation
| @@ -14,7 +14,7 @@ fn main() { | |||
| let try_to_use_system_libgit2 = !vendored && !zlib_ng_compat; | |||
| if try_to_use_system_libgit2 { | |||
| let mut cfg = pkg_config::Config::new(); | |||
| if let Ok(lib) = cfg.range_version("1.4.4".."1.5.0").probe("libgit2") { | |||
There was a problem hiding this comment.
why do we need to support 1.6.0 here already?
There was a problem hiding this comment.
I thought this was a (half-open) non-inclusive range that would not include 1.6.0 itself. Is it not?
There was a problem hiding this comment.
Got to be careful when upgrading libgit2. It doesn't guarantee stable ABI between minor versions.
There was a problem hiding this comment.
@weihanglo The in-repo libgit2 submodule uses a revision from the libgit2 main branch that almost matches libgit2 v1.5.0.
There was a problem hiding this comment.
I'd like to note that this check in and of itself is mostly based on a false premise.
This would make sense if it were attempting to solve API incompatibility issues on compile, but it isn't. It's being used to "solve" ABI incompatibility issues. libgit2, as far as I can tell, does not have an unstable API and only has an unstable ABI. This means that code compiled against libgit2 on ABI change will have to be recompiled, but as long as the API is still the same (which it would seem the API is stable...), no code would need to be changed. Regardless of this changing to 1.6.0 or 1.99.0, the result will still be the same: if the program links the system library, it will have to be recompiled on ABI change (major version change).
See #859.
Fixup for #839
libgit2 1.5.0 was released shortly after it was merged, so switch from
mainto the stablev1.5.0tag and amendcfg.range_versionto include v1.5.0.