3 ms·

> That package has versions This is a statement that doesn't always apply. For example, some packages don't have versions, they only have a single version: th

> That package has versions This is a statement that doesn't always apply. For example, some packages don't have versions, they only have a single version: the latest version. It's a moving target, but it's there. Older versions are just an unimportant and unsupported implementation side-effect. Of course, many packages do have versions, but this one factor makes a big difference on how you look at vendoring.

peq 10y ago
Without versions you don't have package management, you have a download script.
- thawkins 10y ago
  Agreed, and you also cant guarentee reproducable builds. Builds that are dependent on when you compile them, even if no changes have been made due to ephemeral dependances are a nightmare.
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)
mfer 10y ago
There are many people who need versions and don't run the tip of master. Even for projects that always try to keep the tip of master as a stable build. I think of OpenStack here. Multiple times per year they produce releases because many people need them. Yet, the CI/CD system keeps it in such shape you can always run the tip of master and some people do that. Both options need to be available. To not have release versions means you're not willing to support a certain class of users. It says something about your intent.

peq 10y ago

Without versions you don't have package management, you have a download script.

thawkins 10y ago
Agreed, and you also cant guarentee reproducable builds. Builds that are dependent on when you compile them, even if no changes have been made due to ephemeral dependances are a nightmare.

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)

mfer 10y ago

There are many people who need versions and don't run the tip of master. Even for projects that always try to keep the tip of master as a stable build. I think of OpenStack here. Multiple times per year they produce releases because many people need them. Yet, the CI/CD system keeps it in such shape you can always run the tip of master and some people do that. Both options need to be available. To not have release versions means you're not willing to support a certain class of users. It says something about your intent.