5 ms·

Thoughts on a couple of your points: - we don’t need any kind of backwards compatibility, we just update everything. if you don't care about backwards compati

Thoughts on a couple of your points: - we don’t need any kind of backwards compatibility, we just update everything. if you don't care about backwards compatibility, then you can stay on v1 forever. Have you considered a monorepo? That would simplify updating packages and give you the behavior you want. - For the client to update, it’s not a simple path change in go.mod if a package moves from v1 to v2, there are breaking changes in either api or behavior. I think this implies more than a simple change to go.mod. This also allows importing both versions of a package if necessary.

dmitriid 5y ago
> there are breaking changes in either api or behavior. So instead off focusing on those changes I have to first fix potential dozens of files for no reason at all.
- paskozdilar 5y ago
  > So instead off focusing on those changes I have to first fix potential dozens of files for no reason at all. You don't have to, if you don't want to upgrade to a new major version. If you do want to upgrade to a major version, which means that there are breaking changes in a package's API or behavior - you sure as hell want to check the correctness of every single line of code written using that package. Since every file that uses that package must contain an import statement, the import statements are an easily greppable indicator of which files you have to check and potentially fix.
  - dmitriid 5y ago
    > you sure as hell want to check the correctness of every single line of code written using that package Yes, I do. Doing the monkey job of changing every import line (which will be done with a global search/replace) is definitely not that. If you're relying on import statements to tell you which files to check, you're definitely doing something wrong
    - deleted 5y ago
      [deleted]
    - paskozdilar 5y ago
      What mechanism, if not the presence of import statements, do you use to locate all the places where a certain package is used in a large project?
      - dmitriid 5y ago
        1. You build your project, and it fails in the places where API changed. IDEs can even pinpoint those locations without building a project 2. You run tests and they fail if the behavior changed Literally nowhere is "oh, do an automatic search/replace of imports" is a tool for fixing your project or figuring out necessary changes. Except in go, apparently.
        deleted 5y ago
        [deleted]
        paskozdilar 5y ago
        Willingness to play russian roulette with major versions may work in small organizations. In large-scale, you can't risk subtle behavior change that still compiles. That's the source of many black magic debugging sessions.
        dmitriid 5y ago
        Grepping and replacing import paths isn't a good tool for finding subtle behavior changes. Especially in big projects.
        paskozdilar 5y ago
        Yeah, but checking each line of code that uses the import is. Especially in big projects.

dmitriid 5y ago

> there are breaking changes in either api or behavior. So instead off focusing on those changes I have to first fix potential dozens of files for no reason at all.

paskozdilar 5y ago
> So instead off focusing on those changes I have to first fix potential dozens of files for no reason at all. You don't have to, if you don't want to upgrade to a new major version. If you do want to upgrade to a major version, which means that there are breaking changes in a package's API or behavior - you sure as hell want to check the correctness of every single line of code written using that package. Since every file that uses that package must contain an import statement, the import statements are an easily greppable indicator of which files you have to check and potentially fix.
- dmitriid 5y ago
  > you sure as hell want to check the correctness of every single line of code written using that package Yes, I do. Doing the monkey job of changing every import line (which will be done with a global search/replace) is definitely not that. If you're relying on import statements to tell you which files to check, you're definitely doing something wrong
  - deleted 5y ago
    [deleted]
  - paskozdilar 5y ago
    What mechanism, if not the presence of import statements, do you use to locate all the places where a certain package is used in a large project?
    - dmitriid 5y ago
      1. You build your project, and it fails in the places where API changed. IDEs can even pinpoint those locations without building a project 2. You run tests and they fail if the behavior changed Literally nowhere is "oh, do an automatic search/replace of imports" is a tool for fixing your project or figuring out necessary changes. Except in go, apparently.
      - deleted 5y ago
        [deleted]
      - paskozdilar 5y ago
        Willingness to play russian roulette with major versions may work in small organizations. In large-scale, you can't risk subtle behavior change that still compiles. That's the source of many black magic debugging sessions.
        dmitriid 5y ago
        Grepping and replacing import paths isn't a good tool for finding subtle behavior changes. Especially in big projects.
        paskozdilar 5y ago
        Yeah, but checking each line of code that uses the import is. Especially in big projects.