I agree vendoring is essential in some situations, mostly in deployment to production or keeping tight control of libraries used in a project, but I disagree that versioning is not useful in a packaging system.
If you are saying something like having a package X in your vendor lib that depends on packages Y and Z which you don't have vendored... then you haven't done it right. You vendor all dependencies.
No, I'm saying imagine you have an app, which depends on pkgs a and b. a depends on c1.1, b depends on c1.5, but this is documented nowhere in the code because the import statements simply say import "c". This is the default and encouraged behaviour currently with golang and go get. go get a fetches the latest of c.
You then vendor a,b,c and happily compile your app, which doesn't work because the version of c you got when you vendored was 2.1, which neither a nor b was written against. Maybe your app will fail to build and you fix it, maybe your app will build but be wrong in subtle ways (say an enum value changed), without explicit versioning you have no idea really.
If a and b had a vendored c, you have an even more messy situation as security bugs exist in c1.1 and c1.5, but you don't even know which version you have if you pull in the ac and bc and compile against them, or if you can safely use two versions of c at once, your code uses c2.1 too, etc, etc.
Being explicit about versions is helpful for resolving dependency conflicts because it makes it explicit which version was expected at the time of writing, it doesn't magically solve all conflicts, no-one has this completely worked out, but it helps to be as explicit as possible when including other projects, and it is helpful in keeping up to date libraries whilst easily including them, even if you vendor.
If you have a large, open ecosystem of constantly evolving libraries, which I think golang should aspire to, it is useful to version them (just as golang itself is versioned).
If you are saying something like having a package X in your vendor lib that depends on packages Y and Z which you don't have vendored... then you haven't done it right. You vendor all dependencies.
No, I'm saying imagine you have an app, which depends on pkgs a and b. a depends on c1.1, b depends on c1.5, but this is documented nowhere in the code because the import statements simply say import "c". This is the default and encouraged behaviour currently with golang and go get. go get a fetches the latest of c.
You then vendor a,b,c and happily compile your app, which doesn't work because the version of c you got when you vendored was 2.1, which neither a nor b was written against. Maybe your app will fail to build and you fix it, maybe your app will build but be wrong in subtle ways (say an enum value changed), without explicit versioning you have no idea really.
If a and b had a vendored c, you have an even more messy situation as security bugs exist in c1.1 and c1.5, but you don't even know which version you have if you pull in the ac and bc and compile against them, or if you can safely use two versions of c at once, your code uses c2.1 too, etc, etc.
Being explicit about versions is helpful for resolving dependency conflicts because it makes it explicit which version was expected at the time of writing, it doesn't magically solve all conflicts, no-one has this completely worked out, but it helps to be as explicit as possible when including other projects, and it is helpful in keeping up to date libraries whilst easily including them, even if you vendor.
If you have a large, open ecosystem of constantly evolving libraries, which I think golang should aspire to, it is useful to version them (just as golang itself is versioned).