4 ms·

> Expecting library authors to get their design entirely correct the first time round isn't reasonable. People shouldn't be publishing such libraries, nor shou

by wahern 5y ago

> Expecting library authors to get their design entirely correct the first time round isn't reasonable. People shouldn't be publishing such libraries, nor should people be using them. With the exception of my first few FOSS projects, all of my open source libraries represent the 2nd, 3rd, or even 4th incarnation of a concept. That's just being responsible--don't knowingly litter the ecosystem with junk. I take a similar view at work. People are too quick to break out components into modules and libraries, long before they have a firm notion of what a proper interface should look like. If you can't commit to a stable API, then often times it's better to just copy whole functions and files between projects and let them evolve naturally. It takes time to see where that evolution goes, and which commonalities emerge in the implementation and surrounding application. But what about sharing bug and security fixes, you ask? Well, without a stable API you'll invariably end up with different projects stuck using different versions, anyhow. That's why people invented Docker :( What you end up with isn't an actually shared library, just the pretense of sharing, plus a bunch of unnecessary build complexity.

simonw 5y ago
> People shouldn't be publishing such libraries, nor should people be using them. That's why we have pre-1.0 version numbers (and alphas and betas) - they let us release code early for people to provide feedback before we've committed to a non-breaking API. Even with a stable 1.0 release things change. People using the library may come up with logical feature requests that the original design didn't consider, and which require backwards incompatible changes. That's when you bump to a 2.0 release. My dream project would have a version number of something like 1.237 - meaning there have been 237 new features releases since the 1.0 release without backwards compatibility breaks. My hat is off to any project that pulls that off though, it's a rare accomplishment!
- neolog 5y ago
  If the new feature is incompatible with the old library, it's a different library. It should get a different name. If you're all out of names, just append a 2, as in jinja2 or psycopg2. No need to break existing software or to make it impossible to install the new library alongside the existing library.
  - klodolph 5y ago
    That may not be necessary, depending on how everything works. When I use a v2 of a Go library, it doesn’t prevent me from also using v1 somewhere else in the same project.
    - neolog 5y ago
      GP is a python dev, so I'm talking python to him.
  - p1necone 5y ago
    You're basically suggesting reimplementing semver in a clunkier way. Just bump the major version but continue supporting the old major version with security releases etc. This is a solved problem, it's just that some library maintainers don't practice proper communication of breaking changes. If your breaking changes are a total paradigm shift in the intended usage of the library/API then sure, it should be a new library. But quite often those breaking changes are just things like "field Foo is now required when performing process Bar" in order to prevent some sort of invalid state from being reached. In those cases communicating the breaking changes via versioning is the way to go imo.
    - lmm 5y ago
      > You're basically suggesting reimplementing semver in a clunkier way. Just bump the major version but continue supporting the old major version with security releases etc. > This is a solved problem, it's just that some library maintainers don't practice proper communication of breaking changes. It's not just a communication problem, it's also the way that a lot of language tooling works. For example on the JVM you can (mostly) only have a single version of a given (fully qualified) class on a given application's classpath, so it's quite important for incompatible new versions of a library to use a completely new set of class names - thus you'll see e.g. commons-lang3 using org.apache.commons.lang3 alongside commons-lang using org.apache.commons.lang.
    - neolog 5y ago
      Just introduce a new function. Don't break old users.
p1necone 5y ago
Getting a design right the first time is hard, getting a design right without any users is really hard. Also look into how many massive libraries basically started as someones weekend project for fun. I posit that the quality of the open source ecosystem would go down, not up if we tried to somehow enforce these kinds of standards on public projects.

by wahern 5y ago

simonw 5y ago

> People shouldn't be publishing such libraries, nor should people be using them. That's why we have pre-1.0 version numbers (and alphas and betas) - they let us release code early for people to provide feedback before we've committed to a non-breaking API. Even with a stable 1.0 release things change. People using the library may come up with logical feature requests that the original design didn't consider, and which require backwards incompatible changes. That's when you bump to a 2.0 release. My dream project would have a version number of something like 1.237 - meaning there have been 237 new features releases since the 1.0 release without backwards compatibility breaks. My hat is off to any project that pulls that off though, it's a rare accomplishment!

neolog 5y ago
If the new feature is incompatible with the old library, it's a different library. It should get a different name. If you're all out of names, just append a 2, as in jinja2 or psycopg2. No need to break existing software or to make it impossible to install the new library alongside the existing library.
- klodolph 5y ago
  That may not be necessary, depending on how everything works. When I use a v2 of a Go library, it doesn’t prevent me from also using v1 somewhere else in the same project.
  - neolog 5y ago
    GP is a python dev, so I'm talking python to him.
- p1necone 5y ago
  You're basically suggesting reimplementing semver in a clunkier way. Just bump the major version but continue supporting the old major version with security releases etc. This is a solved problem, it's just that some library maintainers don't practice proper communication of breaking changes. If your breaking changes are a total paradigm shift in the intended usage of the library/API then sure, it should be a new library. But quite often those breaking changes are just things like "field Foo is now required when performing process Bar" in order to prevent some sort of invalid state from being reached. In those cases communicating the breaking changes via versioning is the way to go imo.
  - lmm 5y ago
    > You're basically suggesting reimplementing semver in a clunkier way. Just bump the major version but continue supporting the old major version with security releases etc. > This is a solved problem, it's just that some library maintainers don't practice proper communication of breaking changes. It's not just a communication problem, it's also the way that a lot of language tooling works. For example on the JVM you can (mostly) only have a single version of a given (fully qualified) class on a given application's classpath, so it's quite important for incompatible new versions of a library to use a completely new set of class names - thus you'll see e.g. commons-lang3 using org.apache.commons.lang3 alongside commons-lang using org.apache.commons.lang.
  - neolog 5y ago
    Just introduce a new function. Don't break old users.

p1necone 5y ago

Getting a design right the first time is hard, getting a design right without any users is really hard. Also look into how many massive libraries basically started as someones weekend project for fun. I posit that the quality of the open source ecosystem would go down, not up if we tried to somehow enforce these kinds of standards on public projects.