In 1.0 all stdlibs, including Pkg3, are fixed. In some 1.x version, however, we will change that and make it possible to use different stdlib package versions than the Julia version. Since dependencies on stdlibs must be explicitly recorded in your projects already in 1.0, and it’s possible to record the version of a stdlib package that your project depends on in its manifest file, once we support using different stdlib versions, that will allow you to upgrade Julia itself to version 1.x and keep using older versions of stdlib packages – which will keep working because that’s the semver contract for minor updates of Julia. (This may require some trickery in newer stdlib versions since some of them are quite a bit more deeply entangled with Base than typical packages, but fortunately, this kind of thing is fairly doable in a dynamic language.)
This plan allows stdlibs to make breaking API changes while old Julia programs can keep working with newer 1.x versions of Julia by using older versions of stdlibs. This way we follow semver without preventing stdlibs from evolving during the 1.x Julia release cycle. This means that newer versions of stdlibs may have higher version numbers than Julia itself. For example, Julia 1.5 could ship with Dates 2.0 which makes breaking API changes to the Dates stdlib package. This isn’t a semver violation because projects that were written to use Dates 1.4 can continue to do so even while upgrading Julia itself to 1.5.