4 ms·

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.

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.