3 ms·

Er, I don't know anything about rust but cargo is a package manager, right? And the version field you're referring to is what will get checked if someone declar

by fenomas 10y ago

Er, I don't know anything about rust but cargo is a package manager, right? And the version field you're referring to is what will get checked if someone declares a dependency against your package, right? And you're saying semver makes little sense for that?

stormbrew 10y ago
Yes, cargo is the package manager, but it is also the build tool. Whether it's a library or a terminal project (one that has nothing depending on it) you use cargo to build it and it has a Cargo.toml. Even if nothing will ever use your package you will always have to have a version field defined in it.
- amenod 10y ago
  Which makes sense. First of all, cargo can't know that nothing will use your package. And second of all, it is possible that this will change once someone sees how great package you've built. OTOH it costs you nothing to put a number there and never change it if there is no need.
  - irishsultan 10y ago
    It can now that it's not exporting a library and only building executables though.
    - ben0x539 10y ago
      Libraries for shell scripts are made from executables!
- fenomas 10y ago
  Are you suggesting that the field should be optional, or that having the field conform to semver should be optional? If the former, then fair enough but that's orthogonal to the thread. If the latter, that would destroy the package manager's ability to resolve dependencies, right? (Unless new extra metadata was added, or somesuch.) Either way, requiring semver formatting here sounds like its entirely justified.
- stymaar 10y ago
  I agree with you, semver doesn't make sens for every project. But it still make sense for a lot of executables, and not only library, let me illustrate that. Let say you create a cli tool, with a given set of command-line parameters. These parameters are the API your programming is exposing. I can use your program from a shell script for instance, and I will use the existing interface. If, in the next release, you change the options your cli program is accepting, you are actually breaking compatibility with existing integrations including my shell script. Hence this is a breaking change and you should upgrade the major version.
  - stormbrew 10y ago
    I didn't say "it doesn't make sense for executables". I said it makes sense for terminal projects on which nothing has a versioned dependency. This is usually (maybe always) executables, but not all executables fall under that heading. edit: Oh I see. I can see how you'd interpret what I said as implying that [all not libraries] are terminal. I wasn't being exhaustive. :)

by fenomas 10y ago

stormbrew 10y ago

Yes, cargo is the package manager, but it is also the build tool. Whether it's a library or a terminal project (one that has nothing depending on it) you use cargo to build it and it has a Cargo.toml. Even if nothing will ever use your package you will always have to have a version field defined in it.

amenod 10y ago
Which makes sense. First of all, cargo can't know that nothing will use your package. And second of all, it is possible that this will change once someone sees how great package you've built. OTOH it costs you nothing to put a number there and never change it if there is no need.
- irishsultan 10y ago
  It can now that it's not exporting a library and only building executables though.
  - ben0x539 10y ago
    Libraries for shell scripts are made from executables!
fenomas 10y ago
Are you suggesting that the field should be optional, or that having the field conform to semver should be optional? If the former, then fair enough but that's orthogonal to the thread. If the latter, that would destroy the package manager's ability to resolve dependencies, right? (Unless new extra metadata was added, or somesuch.) Either way, requiring semver formatting here sounds like its entirely justified.
stymaar 10y ago
I agree with you, semver doesn't make sens for every project. But it still make sense for a lot of executables, and not only library, let me illustrate that. Let say you create a cli tool, with a given set of command-line parameters. These parameters are the API your programming is exposing. I can use your program from a shell script for instance, and I will use the existing interface. If, in the next release, you change the options your cli program is accepting, you are actually breaking compatibility with existing integrations including my shell script. Hence this is a breaking change and you should upgrade the major version.
- stormbrew 10y ago
  I didn't say "it doesn't make sense for executables". I said it makes sense for terminal projects on which nothing has a versioned dependency. This is usually (maybe always) executables, but not all executables fall under that heading. edit: Oh I see. I can see how you'd interpret what I said as implying that [all not libraries] are terminal. I wasn't being exhaustive. :)