3 ms·

Scala kind of follows semantic versioning. If the first 2 numbers are the same then they are binary compatible (at least starting with version 2.9.0). So vers

Scala kind of follows semantic versioning. If the first 2 numbers are the same then they are binary compatible (at least starting with version 2.9.0). So version 2.9.1 is compatible with 2.9.3. Otherwise they are still source compatible, aside from deprecations, they just need to be recompiled (at least starting with 2.8.0). This article is actually filled with a bunch of mis-information about Scala version compatiblity. For example, the author states: > There has never been a Scala release where it’s been possible to compile and run an older library with a newer version of a program. This is not true at all. There are multiple libraries that support several binary incompatible versions of Scala from the same codebase. Also, as mentioned previously, there are multiple releases of Scala that are binary compatible with each other.

alblue 13y ago
You can't take a library compiled with Scala 2.8 and have it run with Scala 2.10. You can take a library compiled with Java 1.4 and have it run with Java 7. That's the key point that is made here. The fact that version compatibility at the patch level is laughable; that should have been the default, not an additional selling point later. The problem is that it's impossible to create a library (like log4j) and then make it available/support it across different versions. Each time you need to release a build, you have to build different versions - one for 2.9, one for 2.10 - in order to work. At some point that breaks down; one key library in your chain no longer compiles on 2.9, so you have to move everything to 2.10 to do further work. It's the transitive closure for all those libraries and their dependencies that will get you in the end.
- eeperson 13y ago
  Yes, you can't combine libraries compiled for 2.10 and 2.8. No one disputes this. Yes, this is a problem. How much will vary from project to project. However, while you may think that binary compatibility is 'laughable', to imply that there have been no improvements in this area is disingenuous. The presence of this compatibility contradicts the claims you made in the article. You also gloss over source compatibility. Which, again, contradicts the claims you made in the article.

alblue 13y ago

You can't take a library compiled with Scala 2.8 and have it run with Scala 2.10. You can take a library compiled with Java 1.4 and have it run with Java 7. That's the key point that is made here. The fact that version compatibility at the patch level is laughable; that should have been the default, not an additional selling point later. The problem is that it's impossible to create a library (like log4j) and then make it available/support it across different versions. Each time you need to release a build, you have to build different versions - one for 2.9, one for 2.10 - in order to work. At some point that breaks down; one key library in your chain no longer compiles on 2.9, so you have to move everything to 2.10 to do further work. It's the transitive closure for all those libraries and their dependencies that will get you in the end.

eeperson 13y ago
Yes, you can't combine libraries compiled for 2.10 and 2.8. No one disputes this. Yes, this is a problem. How much will vary from project to project. However, while you may think that binary compatibility is 'laughable', to imply that there have been no improvements in this area is disingenuous. The presence of this compatibility contradicts the claims you made in the article. You also gloss over source compatibility. Which, again, contradicts the claims you made in the article.