3 ms·

"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 ei

by 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

by jerf 6y ago

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