It can be used in two modes: a legacy mode in which there is a single Git repository hosted by Jenkins itself, to which you may push changes; and a more general mode in which you may define libraries hosted by any SCM in a location of your choice.
Should it not be the other way around for the modes in configuration? Modern SCM should have option to add SCM.
The best way to specify the SCM is using an SCM plugin which has been specifically updated to support a new API for checking out an arbitrary named version (Modern SCM option). Initially the Git and Subversion plugins have this modification
Choosing Modern SCM there is no option in the drop down list. Neither git nor subversion. Though they are with Legacy SCM.
If your SCM plugin has not been integrated, you may select Legacy SCM and pick anything offered. In this case, you need to include ${library.yourLibName.version} somewhere in the configuration of the SCM, so that during checkout the plugin will expand this variable to select the desired version.
For a library in a git repository would I need to tag a specific version?
---
It is great that we now can use a shared library stored with our own Git remote repository server. However until we transition to that have workflowLibs.git work as before.
If I move the shared library to a different SCM I would probably need to remove workflowLibs.git otherwise how would Jenkins know which one to load as I need to load it implicitly.