7 ms·

They have their reasoning behind this scheme over here: http://blog.llvm.org/2016/12/llvms-new-versioning-scheme.html http://blog.llvm.org/2016/12/llvms-new-ver

by pavanky 10y ago

They have their reasoning behind this scheme over here: http://blog.llvm.org/2016/12/llvms-new-versioning-scheme.html http://blog.llvm.org/2016/12/llvms-new-versioning-scheme.htm... I personally do not agree with their line of reasoning.

falcolas 10y ago
OK, so indeed, no features in between major releases. It's also somewhat unfortunate that, in their words, "every [six month] release is also API breaking". How can you create a stable product that targets a constantly breaking API (short of picking a version and sticking with it)? Of course, I'm a biased, since I consider stable to be measured in years, not months; certainly not the current trend.
- SamBam 10y ago
  But major releases are always expected to be API-breaking, right? Isn't that basically the (SemVer, at least) definition of a major vs minor release? Nothing's forcing anyone to keep up to date, though, so anyone can pick a version and stick with it as long as they like. (So long as they keep making patches for at least the previous version for major bugs...)
  - pavanky 10y ago
    That results in half a dozen versions of LLVM libraries installed on a given machine instead of 1.
    - kbenson 10y ago
      When it comes to a compiler, I think I would rather have a statically linked LLVM in the compiler than a shared object anyway, which would make this moot.
      - deleted 10y ago
        [deleted]
  - _delirium 10y ago
    Major releases in SemVer can break the API, yes. But the alternative a lot of people would like, which is what SemVer contemplates, is to have a distinction between releases that add features without breaking the API, and less frequent releases that break API. For example, following this 4.0.0 release, in the SemVer model there would then be a series of 4.1.x, 4.2.x, etc. releases that add new features with backwards compatibility, followed only sometime considerably later by a 5.x.x that breaks API. However, this isn't how LLVM does things. Instead, there are pure bugfix releases (4.0.x) with no new features, followed by relatively frequent releases that both add features and break API (4.1.x, 4.2.x, etc.).
- kbenson 10y ago
  > How can you create a stable product that targets a constantly breaking API Since it's an open source library, and not a remote resource where you don't have control of what's available and deprecated items being removed, it's less of a problem. You don't have to use the newest version of LLVM if you don't want to. I'm sure at least a few prior major versions will get bug/security fixes if the problems are large enough. That's not to say this is the correct, or best option, but it is one of the ways to go forward, and I would say it's not necessarily a bad way forward when you're still trying to build usage through innovation and features rather than retain usage. Backwards compatibility comes with its own problems, which accrue over time and can eventually strangle a project. Perhaps in the future they will decide to use the minor version number through retaining API compatibility, and thus the major version number, for 3-4 major releases (18-24 months), while still allowing non-breaking changes to go forward. Their versioning rationale doesn't really prevent that, it's just that their current development style and goals do not support it.
  - RX14 10y ago
    Unfortunately the assertion that you control which LLVM version you use isn't always the case. Debian 8 stable is still using LLVM 3.5, while homebrew on OSX and archlinux typically track the latest stable version (currently 3.9). Crystal, the programming language I work on, has to work on both versions and a few in between. (We're dropping support for < 3.8 soon though). Sure, we could bundle a LLVM version with the language, but that has several disadvantages, including size and extra work to build and distribute the package securely. That being said, the changes are typically minor, and while the bindings are a little bit too dense on {% if LibLLVM::IS_38 %} for me [0], it's certainly not hellish yet. However the LLVM debug info generator is a different story... [1] [0] https://github.com/crystal-lang/crystal/blob/c60df09b50829184af88bb062e0723c4939be868/src/llvm/module.cr https://github.com/crystal-lang/crystal/blob/c60df09b5082918... [1] https://github.com/crystal-lang/crystal/blob/master/src/llvm/ext/llvm_ext.cc https://github.com/crystal-lang/crystal/blob/master/src/llvm...
    - saurik 10y ago
      It is my understanding that this is semi-explicit in the culture of the LLVM project as a BSD analog to the architectural damage sometimes described with GCC and GPL: instead of "we don't like supported intermediate data formats, as it allows people to hoard code: if you want to use our code you have to link to it, which will force you to open source your code so it can be upstreamed" they play "we don't like supported APIs, as it allows people to hoard code: if you want to use our code you will spend a lot of your time on the merge treadmill, which will eventually demoralize you into begging for us to upstream your code".
- Joky 10y ago
  It is supposed to be "mostly" API/ABI stable at the C API level. The C++ API is always (and has always been) completely unstable. One way to address it is to have your own wrapper around LLVM that provide the feature you need, and these wrapper can retarget multiple versions of LLVM at will.
  - slrz 10y ago
    How complete is the C API? I'd happily forgo any C++ to get a stable API in return.
    - Joky 10y ago
      Hard to say. I'm pretty sure you can create any piece of IR (almost), and Optimize/CodeGen. We're open to add new APIs when someone needs one that is missing. We only break the C API when there is really no choice. For example when I removed the C++ API getGlobalContext() I made sure to preserve the equivalent C API: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160411/347699.html http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-201... ; but it is not always possible.
- eslaught 10y ago
  > How can you create a stable product that targets a constantly breaking API (short of picking a version and sticking with it)? You don't. This is a cost they explicitly push on consumers of the API. As a consumer, you either spend manpower to keep up-to-date, or if you don't have that luxury, you fall behind and update sporadically. In the open source world for example, there are many volunteer driven projects that use stale versions of LLVM for exactly this reason. This causes a certain amount of churn since projects that don't maintained end up bit-rotting much more quickly than they would otherwise. This has been the de-facto way of things with LLVM for some time, but at least they're making it explicit now.

by pavanky 10y ago

falcolas 10y ago

OK, so indeed, no features in between major releases. It's also somewhat unfortunate that, in their words, "every [six month] release is also API breaking". How can you create a stable product that targets a constantly breaking API (short of picking a version and sticking with it)? Of course, I'm a biased, since I consider stable to be measured in years, not months; certainly not the current trend.

SamBam 10y ago
But major releases are always expected to be API-breaking, right? Isn't that basically the (SemVer, at least) definition of a major vs minor release? Nothing's forcing anyone to keep up to date, though, so anyone can pick a version and stick with it as long as they like. (So long as they keep making patches for at least the previous version for major bugs...)
- pavanky 10y ago
  That results in half a dozen versions of LLVM libraries installed on a given machine instead of 1.
  - kbenson 10y ago
    When it comes to a compiler, I think I would rather have a statically linked LLVM in the compiler than a shared object anyway, which would make this moot.
    - deleted 10y ago
      [deleted]
- _delirium 10y ago
  Major releases in SemVer can break the API, yes. But the alternative a lot of people would like, which is what SemVer contemplates, is to have a distinction between releases that add features without breaking the API, and less frequent releases that break API. For example, following this 4.0.0 release, in the SemVer model there would then be a series of 4.1.x, 4.2.x, etc. releases that add new features with backwards compatibility, followed only sometime considerably later by a 5.x.x that breaks API. However, this isn't how LLVM does things. Instead, there are pure bugfix releases (4.0.x) with no new features, followed by relatively frequent releases that both add features and break API (4.1.x, 4.2.x, etc.).
kbenson 10y ago
> How can you create a stable product that targets a constantly breaking API Since it's an open source library, and not a remote resource where you don't have control of what's available and deprecated items being removed, it's less of a problem. You don't have to use the newest version of LLVM if you don't want to. I'm sure at least a few prior major versions will get bug/security fixes if the problems are large enough. That's not to say this is the correct, or best option, but it is one of the ways to go forward, and I would say it's not necessarily a bad way forward when you're still trying to build usage through innovation and features rather than retain usage. Backwards compatibility comes with its own problems, which accrue over time and can eventually strangle a project. Perhaps in the future they will decide to use the minor version number through retaining API compatibility, and thus the major version number, for 3-4 major releases (18-24 months), while still allowing non-breaking changes to go forward. Their versioning rationale doesn't really prevent that, it's just that their current development style and goals do not support it.
- RX14 10y ago
  Unfortunately the assertion that you control which LLVM version you use isn't always the case. Debian 8 stable is still using LLVM 3.5, while homebrew on OSX and archlinux typically track the latest stable version (currently 3.9). Crystal, the programming language I work on, has to work on both versions and a few in between. (We're dropping support for < 3.8 soon though). Sure, we could bundle a LLVM version with the language, but that has several disadvantages, including size and extra work to build and distribute the package securely. That being said, the changes are typically minor, and while the bindings are a little bit too dense on {% if LibLLVM::IS_38 %} for me [0], it's certainly not hellish yet. However the LLVM debug info generator is a different story... [1] [0] https://github.com/crystal-lang/crystal/blob/c60df09b50829184af88bb062e0723c4939be868/src/llvm/module.cr https://github.com/crystal-lang/crystal/blob/c60df09b5082918... [1] https://github.com/crystal-lang/crystal/blob/master/src/llvm/ext/llvm_ext.cc https://github.com/crystal-lang/crystal/blob/master/src/llvm...
  - saurik 10y ago
    It is my understanding that this is semi-explicit in the culture of the LLVM project as a BSD analog to the architectural damage sometimes described with GCC and GPL: instead of "we don't like supported intermediate data formats, as it allows people to hoard code: if you want to use our code you have to link to it, which will force you to open source your code so it can be upstreamed" they play "we don't like supported APIs, as it allows people to hoard code: if you want to use our code you will spend a lot of your time on the merge treadmill, which will eventually demoralize you into begging for us to upstream your code".
Joky 10y ago
It is supposed to be "mostly" API/ABI stable at the C API level. The C++ API is always (and has always been) completely unstable. One way to address it is to have your own wrapper around LLVM that provide the feature you need, and these wrapper can retarget multiple versions of LLVM at will.
- slrz 10y ago
  How complete is the C API? I'd happily forgo any C++ to get a stable API in return.
  - Joky 10y ago
    Hard to say. I'm pretty sure you can create any piece of IR (almost), and Optimize/CodeGen. We're open to add new APIs when someone needs one that is missing. We only break the C API when there is really no choice. For example when I removed the C++ API getGlobalContext() I made sure to preserve the equivalent C API: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160411/347699.html http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-201... ; but it is not always possible.
eslaught 10y ago
> How can you create a stable product that targets a constantly breaking API (short of picking a version and sticking with it)? You don't. This is a cost they explicitly push on consumers of the API. As a consumer, you either spend manpower to keep up-to-date, or if you don't have that luxury, you fall behind and update sporadically. In the open source world for example, there are many volunteer driven projects that use stale versions of LLVM for exactly this reason. This causes a certain amount of churn since projects that don't maintained end up bit-rotting much more quickly than they would otherwise. This has been the de-facto way of things with LLVM for some time, but at least they're making it explicit now.