4 ms·

Does scala follow semantic versioning? It sounds like they should still be in the 0.x stage if there are enough breaking changes to merit this discussion

lmm 13y ago
It follows semantic versioning at the source level, more or less (there are things like new keywords, but not breaking changes to the semantics of existing functionality). When a new minor version of scala comes out you bump up the number in your build tool and it fetches new versions of your libraries (we've standardized how to represent binary compatibility of libraries) and rebuilds your program. It's really no big deal.
jkrems 13y ago
0.x does not mean "unstable" in semantic versioning. If you don't have any stable interface, not using a version would maybe semantic. With semantic versioning they should rather be at Scala 11.x or 23.x (each breaking change bumps the major).
- nonchalance 13y ago
  http://semver.org/ http://semver.org/ > Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable. major version 0 was specifically designed for this use case
  - ssmoot 13y ago
    The public API at the source level is very stable. I mean, my major touchstone is Ruby-land, and over there there's nothing like it. Even point releases of libraries or the language itself can and will routinely break your code. I've never seen that happen with Scala. Not saying it definitively hasn't, but I certainly haven't experienced it, and that's not because I'm using less of Scala than I did of Ruby... It feels like shifting the goal posts to say that binary compatibility should be a bigger factor in versioning (and it's already represented in the minor version) when you've already arguably got better stability guarantees than many of it's contemporaries. Unless we really are limiting the conversation to Java. But how do you compete with "we never break compatibility at the cost of never evolving"?
ssmoot 13y ago
Yes it does. AFAICT it's working well. There are 5 releases in the 2.10.x line and I haven't had a compatibility issue between any of them. The deal is (I think) that Scala is a much quicker evolving language than say Ruby. Ruby 2.0 was rumored to be released the better part of a decade ago (anyone else remember Pickaxe 1.8, pre-Rails, saying that eventually parenthesis would no longer be optional in Ruby 2.0?). Scala has developed new features at a pretty quick pace. By and large this doesn't mean breaking source compatibility. Most source seems to be forwards compatible, or require minimal effort. The reason this comes up at all is because of Package Management. Where Ruby only needs to worry about a parser compatibility level, Scala has to worry about binary compatibility in packaging since it lives in Java's packaging ecosystem. Since Maven doesn't encode a binary version, breaking binary compatibility (say you added a new default argument to a method signature, that wouldn't otherwise break source compatibility, or you introduced a new superclass for a return value) means breaking your packages. SBT gets around this by encoding the binary version (the Scala minor version) in the artifact name. Some day this will all probably get sorted out. It hasn't been much of a pain point for me personally. Most 3rd party binary packages are Java packages, which are binary compatible since Java 5(?). For the few Scala libs you might depend on, you might as likely be using a source dependency from Github, which means you don't need to worry since you're compiling it yourself, or most popular packages will have published versions with a new compiler pretty quickly. The next time this will be an issue is when Scala 2.11.0 is released. And AFAIK that should introduce any breaking changes for source code at this point. So if you want to move to Scala 2.11.0 you either wait for package authors to cross-compile to it, or you build it yourself as a source dependency if you have access to the code.
- alblue 13y ago
  Just FYI; semantic versioning is split into three numbers: major.minor.micro Changes in .micro are assumed to be interchangeable. Scala does this. Changes in .minor are assumed to be backwardly compatible, but with new features added. Scala does not do this, it requires a recompile. Major versions indicate a completely incompatible change. If Scala were to follow semantic versioning, it would need to coalesce the first two versions together and have e.g. 210 and 211 to indicate that they are not compatible with each other.
eeperson 13y ago
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.

lmm 13y ago

It follows semantic versioning at the source level, more or less (there are things like new keywords, but not breaking changes to the semantics of existing functionality). When a new minor version of scala comes out you bump up the number in your build tool and it fetches new versions of your libraries (we've standardized how to represent binary compatibility of libraries) and rebuilds your program. It's really no big deal.

jkrems 13y ago

0.x does not mean "unstable" in semantic versioning. If you don't have any stable interface, not using a version would maybe semantic. With semantic versioning they should rather be at Scala 11.x or 23.x (each breaking change bumps the major).

nonchalance 13y ago
http://semver.org/ http://semver.org/ > Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable. major version 0 was specifically designed for this use case
- ssmoot 13y ago
  The public API at the source level is very stable. I mean, my major touchstone is Ruby-land, and over there there's nothing like it. Even point releases of libraries or the language itself can and will routinely break your code. I've never seen that happen with Scala. Not saying it definitively hasn't, but I certainly haven't experienced it, and that's not because I'm using less of Scala than I did of Ruby... It feels like shifting the goal posts to say that binary compatibility should be a bigger factor in versioning (and it's already represented in the minor version) when you've already arguably got better stability guarantees than many of it's contemporaries. Unless we really are limiting the conversation to Java. But how do you compete with "we never break compatibility at the cost of never evolving"?

ssmoot 13y ago

Yes it does. AFAICT it's working well. There are 5 releases in the 2.10.x line and I haven't had a compatibility issue between any of them. The deal is (I think) that Scala is a much quicker evolving language than say Ruby. Ruby 2.0 was rumored to be released the better part of a decade ago (anyone else remember Pickaxe 1.8, pre-Rails, saying that eventually parenthesis would no longer be optional in Ruby 2.0?). Scala has developed new features at a pretty quick pace. By and large this doesn't mean breaking source compatibility. Most source seems to be forwards compatible, or require minimal effort. The reason this comes up at all is because of Package Management. Where Ruby only needs to worry about a parser compatibility level, Scala has to worry about binary compatibility in packaging since it lives in Java's packaging ecosystem. Since Maven doesn't encode a binary version, breaking binary compatibility (say you added a new default argument to a method signature, that wouldn't otherwise break source compatibility, or you introduced a new superclass for a return value) means breaking your packages. SBT gets around this by encoding the binary version (the Scala minor version) in the artifact name. Some day this will all probably get sorted out. It hasn't been much of a pain point for me personally. Most 3rd party binary packages are Java packages, which are binary compatible since Java 5(?). For the few Scala libs you might depend on, you might as likely be using a source dependency from Github, which means you don't need to worry since you're compiling it yourself, or most popular packages will have published versions with a new compiler pretty quickly. The next time this will be an issue is when Scala 2.11.0 is released. And AFAIK that should introduce any breaking changes for source code at this point. So if you want to move to Scala 2.11.0 you either wait for package authors to cross-compile to it, or you build it yourself as a source dependency if you have access to the code.

alblue 13y ago
Just FYI; semantic versioning is split into three numbers: major.minor.micro Changes in .micro are assumed to be interchangeable. Scala does this. Changes in .minor are assumed to be backwardly compatible, but with new features added. Scala does not do this, it requires a recompile. Major versions indicate a completely incompatible change. If Scala were to follow semantic versioning, it would need to coalesce the first two versions together and have e.g. 210 and 211 to indicate that they are not compatible with each other.

eeperson 13y ago

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.