5 ms·

What I dislike about Go's solution, and somewhat about semver in general is that no one makes major version changes anymore even if they break backwards compati

What I dislike about Go's solution, and somewhat about semver in general is that no one makes major version changes anymore even if they break backwards compatibility. However if I use semver internally, like it's supposed to and make regular major changes (let's say once a month), my code repo becomes a mess. After a 2 years, I'll have folders for v1 up to v24. And the fact that I have to copy -R/grep|sed, means that people will be less likely to properly signal that a backwards incompatible change has occured. Disregarding uniformity, for the reasons above I don't think their design is a good one. It treats major version changes as a rare event.

andrewprock 6y ago
For a designed library, major version changes should be a rare event. For a collection of code that someone calls a library, all bets are off.
- Aeolun 6y ago
  What open source project is a designed library? This will just pollute the API interface for the sake of maintaining backwards compatibility.
  - slavik81 6y ago
    Qt hasn't broken binary compatibility since the release of Qt 5.0 in 2012. The last one before that was the release of Qt 4.0 in 2005. It's a very impressive standard they set out for themselves (and met). https://wiki.qt.io/Qt-Version-Compatibility https://wiki.qt.io/Qt-Version-Compatibility
- jerf 6y ago
  "For a designed library, major version changes should be a rare event." If you properly honor semver, for any non-static library, major version changes will either be a modestly-frequent event, or you're really straightjacketing yourself with your first v1, or you're a genius who got everything right the first time and never have to make any changes. Or, most likely, you're not honoring semver properly and kindasorta squint at your changes until they don't seem important anymore and then ship an incremental anyhow. Go may make it somewhat more annoying than the average language to ship a new major version in some ways, but libraries either not rev'ing their major version number when they technically should have and mostly expecting to mostly get away with it, or libraries bending themselves slowly into pretzels to stay on the same major version according to semver when they really ought to just make a new major version are things I see in many languages.
  - wahern 6y ago
    > If you properly honor semver, for any non-static library, major version changes will either be a modestly-frequent event, or you're really straightjacketing yourself with your first v1, or you're a genius who got everything right the first time and never have to make any changes. IMO, someone tackling a problem for the first time shouldn't be writing public libraries. At the very least, people shouldn't be using it. Quality, stable libraries tend to be written by people who already have at least 1 or 2 iterations under their belt. Maybe not complete iterations, and rarely public, but enough experience with the nuts & bolts of the problem, including the problem of balancing concerns between caller & callee, to have a good idea about what the proper interfaces should look like to ensure long-term stability. If someone doesn't have a strong sense that they could support the v1 interface in perpetuity, then maybe don't create a separate project. Not only does it save everybody else from the pain, it often saves the author the pain of constant churn, presuming the author even uses it in more than a handful of their own projects. For many of my own open source projects, I often have years of abandoned false starts lying around, or various just-so solutions manually copied and hacked into various other projects. Only when I feel like things have finally congealed do I then bother to write a dedicated library, whether private or public, and migrate everything to it. One way to know things are looking good is when you realize you're no longer fiddling with the API, or maybe just vacillating between two equally decent alternatives.
  - bigiain 6y ago
    > you're really straightjacketing yourself with your first v1, or you're a genius who got everything right the first time and never have to make any changes In my head - that's what v0 is for. Many people try to jump the v1 gun well before they've allowed the real world to impose itself on the unwarranted assumptions that should have been shaken out in v0
- gravypod 6y ago
  Rarely is not never. "For a well architect house, fires should occur very rarely. As such we should not install smoke alarms." If it can happen it will happen and whatever you're designing should be built with that in mind. Say nothing of an entire language's package management semantics
  - Skinney 6y ago
    There is a big gap between "breaking changes every month" and every couple of years.
    - gravypod 6y ago
      That doesn't really matter. For a large enough code base "a breaking change every couple of years" for each library in your source tree could easily be a breaking change every every day. When the surface you're looking at is "all open source code supporting this language" are you confident saying that there will only be 1 breaking change every 2 years for your tools? Imagine you're making a GUI. I don't think there's any GUI lib in the mobile OS space that hasn't added or deprecated a major feature in the last 2 years. Android is very good at this and there's still large deprecation events (see Jetpack).
      - Skinney 6y ago
        I picked up a Clojure project I wrote three-four years ago last month and upgraded it to all its latest dependencies. No breaking changes. The HTML-based applications I've written going back the last six years all still work on modern browsers. The few apps I've written for Android didn't work across all Android versions even when in active development. Android really is the best example of how miserable development can be when backwards compatibility (or really, just compatibility) isn't taken seriously.
infogulch 6y ago
If you write something for internal use and can enforce version upgrades could you not just keep the last, say, 3 versions in the repo HEAD and delete folders v1-v20? Between go.mod and go.sum, historical dependencies will still resolve fine because they point at the old commit. If you know you will never release another patch for a particular major version I think you could just drop the directory from the repo.
Skinney 6y ago
If you're introducing breaking changes once per month, then your library really isn't ready. Tell people you have an unstable library. Breaking changes _will_ happen. Then, when you've used your library in production for a while and are reasonably sure it wont have to change, tell people it's stable. If you make breaking changes after that, then start with a v2 suffix. For some reason, semver has made people stop going through the alpha, beta and rc stages of a release, even though the point of such things is to discover breaking changes before you're commited to maintaining the version for the time to come. Major version changes should be a rare event. If it's not, you're really just shipping around a (pre)alpha library, and should be explicit about that.
- barumi 6y ago
  > If you're introducing breaking changes once per month, then your library really isn't ready. The whole software industry moved away from waterfall to agile because it's unreasonable to assume that no requirements will emerge. I would disagree, for example, that Python3 is not ready just because they're introduced backward incompatible changes in some minor releases.
  - tick_tock_tick 6y ago
    I mean python is basically the prime example of how to poorly manage version upgrades with their failure of 2 => 3.
    - bigiain 6y ago
      They were just desperate to do a better job of screwing up than Perl with it's 5 => 6 updates... <grin>
      - masklinn 6y ago
        As we can see from the Perl ecosystem having completely moved over to the extent that Perl 5 is now out of support while Python is still mired in the update.
atombender 6y ago
Go doesn't require a folder for each version. You can simply change go.mod to declare the module as github.com/nemothekid/foolib/v2 or whatever. That's one of the points of confusion — first that the go.mod module declaration doesn't need to exactly match the module location, and secondly, following this, that using a folder instead is a fallback option. Go is famous for favouring simplicity in its design, but this is a rare instance where it's not made things simple enough.
- deleted 6y ago
  [deleted]

andrewprock 6y ago

For a designed library, major version changes should be a rare event. For a collection of code that someone calls a library, all bets are off.

Aeolun 6y ago
What open source project is a designed library? This will just pollute the API interface for the sake of maintaining backwards compatibility.
- slavik81 6y ago
  Qt hasn't broken binary compatibility since the release of Qt 5.0 in 2012. The last one before that was the release of Qt 4.0 in 2005. It's a very impressive standard they set out for themselves (and met). https://wiki.qt.io/Qt-Version-Compatibility https://wiki.qt.io/Qt-Version-Compatibility
jerf 6y ago
"For a designed library, major version changes should be a rare event." If you properly honor semver, for any non-static library, major version changes will either be a modestly-frequent event, or you're really straightjacketing yourself with your first v1, or you're a genius who got everything right the first time and never have to make any changes. Or, most likely, you're not honoring semver properly and kindasorta squint at your changes until they don't seem important anymore and then ship an incremental anyhow. Go may make it somewhat more annoying than the average language to ship a new major version in some ways, but libraries either not rev'ing their major version number when they technically should have and mostly expecting to mostly get away with it, or libraries bending themselves slowly into pretzels to stay on the same major version according to semver when they really ought to just make a new major version are things I see in many languages.
- wahern 6y ago
  > If you properly honor semver, for any non-static library, major version changes will either be a modestly-frequent event, or you're really straightjacketing yourself with your first v1, or you're a genius who got everything right the first time and never have to make any changes. IMO, someone tackling a problem for the first time shouldn't be writing public libraries. At the very least, people shouldn't be using it. Quality, stable libraries tend to be written by people who already have at least 1 or 2 iterations under their belt. Maybe not complete iterations, and rarely public, but enough experience with the nuts & bolts of the problem, including the problem of balancing concerns between caller & callee, to have a good idea about what the proper interfaces should look like to ensure long-term stability. If someone doesn't have a strong sense that they could support the v1 interface in perpetuity, then maybe don't create a separate project. Not only does it save everybody else from the pain, it often saves the author the pain of constant churn, presuming the author even uses it in more than a handful of their own projects. For many of my own open source projects, I often have years of abandoned false starts lying around, or various just-so solutions manually copied and hacked into various other projects. Only when I feel like things have finally congealed do I then bother to write a dedicated library, whether private or public, and migrate everything to it. One way to know things are looking good is when you realize you're no longer fiddling with the API, or maybe just vacillating between two equally decent alternatives.
- bigiain 6y ago
  > you're really straightjacketing yourself with your first v1, or you're a genius who got everything right the first time and never have to make any changes In my head - that's what v0 is for. Many people try to jump the v1 gun well before they've allowed the real world to impose itself on the unwarranted assumptions that should have been shaken out in v0
gravypod 6y ago
Rarely is not never. "For a well architect house, fires should occur very rarely. As such we should not install smoke alarms." If it can happen it will happen and whatever you're designing should be built with that in mind. Say nothing of an entire language's package management semantics
- Skinney 6y ago
  There is a big gap between "breaking changes every month" and every couple of years.
  - gravypod 6y ago
    That doesn't really matter. For a large enough code base "a breaking change every couple of years" for each library in your source tree could easily be a breaking change every every day. When the surface you're looking at is "all open source code supporting this language" are you confident saying that there will only be 1 breaking change every 2 years for your tools? Imagine you're making a GUI. I don't think there's any GUI lib in the mobile OS space that hasn't added or deprecated a major feature in the last 2 years. Android is very good at this and there's still large deprecation events (see Jetpack).
    - Skinney 6y ago
      I picked up a Clojure project I wrote three-four years ago last month and upgraded it to all its latest dependencies. No breaking changes. The HTML-based applications I've written going back the last six years all still work on modern browsers. The few apps I've written for Android didn't work across all Android versions even when in active development. Android really is the best example of how miserable development can be when backwards compatibility (or really, just compatibility) isn't taken seriously.

infogulch 6y ago

If you write something for internal use and can enforce version upgrades could you not just keep the last, say, 3 versions in the repo HEAD and delete folders v1-v20? Between go.mod and go.sum, historical dependencies will still resolve fine because they point at the old commit. If you know you will never release another patch for a particular major version I think you could just drop the directory from the repo.

Skinney 6y ago

If you're introducing breaking changes once per month, then your library really isn't ready. Tell people you have an unstable library. Breaking changes _will_ happen. Then, when you've used your library in production for a while and are reasonably sure it wont have to change, tell people it's stable. If you make breaking changes after that, then start with a v2 suffix. For some reason, semver has made people stop going through the alpha, beta and rc stages of a release, even though the point of such things is to discover breaking changes before you're commited to maintaining the version for the time to come. Major version changes should be a rare event. If it's not, you're really just shipping around a (pre)alpha library, and should be explicit about that.

barumi 6y ago
> If you're introducing breaking changes once per month, then your library really isn't ready. The whole software industry moved away from waterfall to agile because it's unreasonable to assume that no requirements will emerge. I would disagree, for example, that Python3 is not ready just because they're introduced backward incompatible changes in some minor releases.
- tick_tock_tick 6y ago
  I mean python is basically the prime example of how to poorly manage version upgrades with their failure of 2 => 3.
  - bigiain 6y ago
    They were just desperate to do a better job of screwing up than Perl with it's 5 => 6 updates... <grin>
    - masklinn 6y ago
      As we can see from the Perl ecosystem having completely moved over to the extent that Perl 5 is now out of support while Python is still mired in the update.

atombender 6y ago

Go doesn't require a folder for each version. You can simply change go.mod to declare the module as github.com/nemothekid/foolib/v2 or whatever. That's one of the points of confusion — first that the go.mod module declaration doesn't need to exactly match the module location, and secondly, following this, that using a folder instead is a fallback option. Go is famous for favouring simplicity in its design, but this is a rare instance where it's not made things simple enough.

deleted 6y ago
[deleted]