27 ms·

First, your described software still has versions. Each daily snapshot or git commit or whatever is a new version. There's no reason you can't put an auto-inc

by vec 10y ago

First, your described software still has versions. Each daily snapshot or git commit or whatever is a new version. There's no reason you can't put an auto-incrementing version number on each release and call that your version number. You can even stick a "0." on the front of it and be SemVer complant. Second, just because some people do this doesn't mean it's a good idea. If you're writing a full application and just want to distribute it, do whatever you want with your versioning (although using a dependency management tool to distribute your webapp or CLI tool is probably not a great idea in the first place), but if you are writing something to be included in another project please use a sane versioning system. Anything else is selfish and disrespectful of your users.

bassislife 10y ago
In Go, each version corresponds to a given import/Pkg path. If you want to change version (major), you need to create a new package. The advantage is that you do not have to download a manifest such as package.json or whatever. It also provides a constraint on library authors to provide a backward compatible API for their published package. Eventually, I guess we could use go/types to enforce/check the API backward compatibility requirement. The main issues for now are: * make sure that packages importing a same vendored one are able to use the same latest minor version in use. * allow a project based approach to go get for people who need reproducible builds (or alternatively allow for multiple $GOPATH and make being able to switch between them easy)