Open raboof opened 2 years ago
I just hit against this trying to resolve some vuln scanner warnings urging upgrade to jgit 6.6.1 minimally, but my own projects still require Java 8.
Thanks for sharing - the fact that there are apparently now security advisories for the version of JGit we're depending on might be another reason to start requiring Java 11 in sbt-git, but since it is possible to avoid the library (via useReadableConsoleGit
) perhaps we should still wait for typelevel.
OTOH, typelevel can stick to the currently-released version of sbt-git until they're requiring Java 11 as well.
Is the latest JGit binary-compatible with the version used in this plugin? i.e. can the user just upgrade the JGit version themselves by adding an explicit dependency, instead of doing the upgrade in sbt-git and forcing it on everyone?
I have no idea, but since it's a major version change I presume not.
This also likely means sbt-git is now incompatible with any plugin that wants to use a recent version of JGit.
I'm in no rush to upgrade jgit, but if there's any strong reason to (e.g. when worktree support finally lands) I'd support it. Maybe we could still target jdk8 bytecode in sbt-git to leave some wiggle room for projects that are still built on JDK 8, but I don't think we should be going out of our way to support that - if all else fails they can just keep using the already-released versions.
I imagine it might take some work, but could sbt-git catch the jgit classloader exception and fall back to using the git executable?
I.e. fall back unless useJGit
is true or useReadableConsoleGit
is false?
Currently, upgrading JGit to version 6 is blocked because we still support Java 8 and they already require Java 11.
We should probably stick with Java 8 as long as (for example) typelevel projects like cats are still building on it (https://github.com/typelevel/cats/blob/main/build.sbt#L33), and consider updating after they do.