I wrote a similar issue in 1891 for dep - I feel there has been a heavy amount of talk and effort around algorithms for version selection and those are important. But for a vast majority of projects migrating I don't think there is a better version than what the project is currently compiling with today. Both dep and vgo are discarding all the context provided by the current workspace, I think they should use it if available and then fall back to version selection.

I don't understand all the details of the version selection algorithm I read in the blog posts so I can't comment from a technical position, I can only report as an end user that I believe selecting a 4 year old alpha version of a repo is a bit unexpected.

This comment has been minimized.

Thanks @myitcv, I'll give your suggestion a try in the future. I do feel like building projects has been solved for in the least common use case: a clean code base or projects that already use an existing package manager. Well we have 8 years of software out there today that was written without any of these things, I personally never moved to dep because of issues early on and I was waiting for the Go team to full buy into a solution. I feel as an end user experience, nothing could be better than giving the user a starting point of.. their current starting point. Then providing a sub command to take a path forward, this lets the user immediately migrate and start enjoying reproducible builds and slowly upgrade dependencies in a controlled way (at that point the version selection algorithms are really useful). Maybe I'm the minority though I don't know.

This means using a vgo migrate and a vgo update [--all, -a false] [pkg...] with either a vgo list or vgo update with a --dry-run flag. This covers the way I want to migrate to a new way of writing Go code, which is the way I want to migrate to a new way of literally anything. Small, measurable steps. Right now switching to vgo or dep means changing every single dependency which introduces failed compilations for a process that is unfamiliar to you. Far worst would be the cases when the upgrades allow compilation but introduce a production only bug, anyone first suspicion would be "vgo broke my code!" "it was working fine before vgo!".

Eventually my initial migration state will have caught up to what vgo is designed for and all is well. The experience would be seamless and pain free. I understand the caveats of checking the current work space, I get there is only so far you can go in some cases. Maybe repos that don't have git information in the vendor directory for example, could you still determine the version? Yes. Maybe not worth the compute cycles to do so though (iterate up / down comparing files and then hashes from closest revision matching the same set of files or something? not sure), but maybe it is.

Maybe this is unreasonable and I am a small minority, I know there is nothing stopping me from writing a tool that does this process and I just might do that. To be clear this isn't a proposal, consider it a detailed experience report from a decent sized internal project with >50 dependencies to maybe stir some thought. Thanks for the efforts spent on vgo thus far, I feel the entire Go ecosystem will benefit greatly once it is in wide spread use. I just hope the migration process becomes less painful, because the quicker everyone migrates the better the experience for everyone will be.