3 ms·

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,

by 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.
- jnxx 5y ago
  > You're basically suggesting reimplementing semver in a clunkier way. There is a huge difference: Most languages and runtimes do not support having the same dynamic library twice in the same process. This means that if you just bump the major version number, you can only have one version of a library in a process. Now consider the case that your library L1 has a dependency L2 and is included in an application A which also includes another library L3 which has the same dependency L2 as you. Now think what happens if L2 has a breaking change, and you upgrade L1 to use the new version, but L3 does not work with the new version, and does not upgrade it. In this case, the application A - the user of your library - is broken, and there is little the developer of A can do about it. However, there are two kinds of libraries: One which access global objects, like GUI libraries, the glibc socket library, and such. Or which provide data interchange formats, such as Python's Numpy. These regularly need to be unique across an implementation. And the other ones which do things like data transformation, parsing configuration, some numeric processing, and such. In this case, you could link L2 statically, if you were using C. r you could L2v2 and the library l3 could use L2v1. But in most languages and runtimes, this will only work if L2 version 1 and the incompatible L2 version 2 have a different name. > Just bump the major version but continue supporting the old major version with security releases etc. My experience is that the "continue supporting the old major version with security releases etc" almost never happens. People release incompatible versions and force upgrades on users because they do not want to do extra work. If they were supporting older versions, they would still have to do some of the extra work. They might do it some time in some cases but even then they will cease to do it soon. If one wants continuous updates and support, one is usually MUCH better off to use libraries which just do not do compatibility-breaking changes. Because these have decided to do the work required up-front, and have little extra work with supplying urgent fixes to an old API interface.
  - neolog 5y ago
    > One which access global objects, like GUI libraries, the glibc socket library, and such. Or which provide data interchange formats, such as Python's Numpy. These regularly need to be unique across an implementation. Could you explain why each of these libraries needs to be unique in a runtime instance? I don't know much about GUIs or networking, but numpy doesn't seem like it needs to be unique.
jnxx 5y ago
Also, it is easy and much less disruptive to declare new features (and not the whole API) as unstable while they still may change, and promise stability for the rest.

by neolog 5y ago

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.
jnxx 5y ago
> You're basically suggesting reimplementing semver in a clunkier way. There is a huge difference: Most languages and runtimes do not support having the same dynamic library twice in the same process. This means that if you just bump the major version number, you can only have one version of a library in a process. Now consider the case that your library L1 has a dependency L2 and is included in an application A which also includes another library L3 which has the same dependency L2 as you. Now think what happens if L2 has a breaking change, and you upgrade L1 to use the new version, but L3 does not work with the new version, and does not upgrade it. In this case, the application A - the user of your library - is broken, and there is little the developer of A can do about it. However, there are two kinds of libraries: One which access global objects, like GUI libraries, the glibc socket library, and such. Or which provide data interchange formats, such as Python's Numpy. These regularly need to be unique across an implementation. And the other ones which do things like data transformation, parsing configuration, some numeric processing, and such. In this case, you could link L2 statically, if you were using C. r you could L2v2 and the library l3 could use L2v1. But in most languages and runtimes, this will only work if L2 version 1 and the incompatible L2 version 2 have a different name. > Just bump the major version but continue supporting the old major version with security releases etc. My experience is that the "continue supporting the old major version with security releases etc" almost never happens. People release incompatible versions and force upgrades on users because they do not want to do extra work. If they were supporting older versions, they would still have to do some of the extra work. They might do it some time in some cases but even then they will cease to do it soon. If one wants continuous updates and support, one is usually MUCH better off to use libraries which just do not do compatibility-breaking changes. Because these have decided to do the work required up-front, and have little extra work with supplying urgent fixes to an old API interface.
- neolog 5y ago
  > One which access global objects, like GUI libraries, the glibc socket library, and such. Or which provide data interchange formats, such as Python's Numpy. These regularly need to be unique across an implementation. Could you explain why each of these libraries needs to be unique in a runtime instance? I don't know much about GUIs or networking, but numpy doesn't seem like it needs to be unique.

jnxx 5y ago

Also, it is easy and much less disruptive to declare new features (and not the whole API) as unstable while they still may change, and promise stability for the rest.