4 ms·

I feel like LLVM 3.4 and GCC 4.8 were around for ages and now they increment major versions every time I reinstall Linux. Is it just me? Why do compiler versio

I feel like LLVM 3.4 and GCC 4.8 were around for ages and now they increment major versions every time I reinstall Linux. Is it just me? Why do compiler version numbers increase so faster now? (I read these release notes, it seems quite nice but is it a major version?)

ktta 7y ago
They changed the way versioning is done around 3.9's release. http://blog.llvm.org/2016/12/llvms-new-versioning-scheme.html http://blog.llvm.org/2016/12/llvms-new-versioning-scheme.htm... I feel they are changing the version too quickly (I usually keep an eye out for the major version bumps, and with LLVM I just ignore them now)
- eslaught 7y ago
  Here's the HN discussion from when this was posted: https://news.ycombinator.com/item?id=13179903 https://news.ycombinator.com/item?id=13179903 Personally, though I agree the version number is going up too quickly, I appreciate that it at least aligns with their policy on breaking changes (which is to provide no hard guarantees on backwards compatibility).
- loeg 7y ago
  Ditto GCC after 4.x.[1] 4.0.0-4.9.4 (last) was Apr 2005 - Dec 2016. Almost 12 years. Starting in 5.x they dropped the 3rd release digit and started bumping the major version more frequently. Between Apr 2015 and the present, GCC has put out 5.x, 6.x, 7.x, 8.x, and 9.x. [1]: https://gcc.gnu.org/releases.html https://gcc.gnu.org/releases.html
- aseipp 7y ago
  Why would you ignore it because of that? LLVM's release cycle is short-ish, but its version bumps are precisely the kind you should pay attention to -- it's a project that changes rapidly with a large amount of features and many stakeholders. Breaks, as well as major new functionality, are common between releases. I don't see why the version today being 12 or 4.10 or whatever makes a difference to this. It's extremely worth keeping an eye on if you're invested in LLVM either way (as a user, downstream consumer, corporation, whatever.) This has been true since major corporate involvement started as long as 10 years ago or more... If anything, as another user mentioned, this version scheme is probably more honest to the way LLVM actually works anyway, because in practice every release has major breaking changes, and this scheme (in theory) better reflects that. At least with Firefox, most versions N and N+1 don't just visibly break tons of functionality for a user, so you could argue the increase is too rapid for what are (mostly) incremental changes. But LLVM's client base is much more vulnerable to major change and in practice it does break tons of APIs and make tons of changes release-to-release.
jpfr 7y ago
The same is happening with Firefox. Many "infrastructure" software projects have switched to time-based releases. Say, a release every 6 months. So there is no notion of big or small releases. Hence the seemingly fast increase of version numbers.
- sdegutis 7y ago
  It makes sense. Version numbers should be intuitive. Constantly changing software should update by whole numbers, so that the more it has changed, the more the number is different. Whereas "3.11" seems almost identical to "3.86" because they're both based on 3. Although I would argue that it should change by 0.5 per feature or something like that, so that if it has 10 new features the version number will be 5 higher, but only 2 new features will be 1 higher. Because Java has changed very little from 8 to 12, whereas Firefox's last 4 changes were altogether bigger.
- asveikau 7y ago
  You can still do a time based release without jumping major versions so often. Eg. OpenBSD's version number increments by 0.1 every six months and has done that for more than 20 years.
tveita 7y ago
Numba the Python library is only just getting around to support LLVM 9. https://github.com/numba/llvmlite/issues/523 https://github.com/numba/llvmlite/issues/523
klodolph 7y ago
2.x - 9 years 3.x - 4 years 4.x - 10 years Honestly, if nothing else, I hated seeing all the #if defined __GNUC__ && (__GNUC__ > 4 || __GNUC__ == 4 && __GNUC_MINOR__ >= 2)
- wahern 7y ago
  Fortunately these days you're supposed to use __has_attribute, __has_extension, and __has_builtin. But I'm not sure if, overall, things have gotten better. For example, overly eager diagnostic warnings have come at the cost of an increased need to disable diagnostics--perfectly standard-compliant code, not to mention widely supported extensions, will often trigger diagnostics with -Wall. You can disable those inline (and I try, because good luck trying to figure out what's the equivalent of CFLAGS in the build pipeline du jour, or simply expecting the user to figure it out), but they often have different names in different compilers and sometimes you have to resort to version guards to maintain a diagnostic-free build out-of-the-box. Also, the default compiler on RHEL7 is GCC 4.8, which lacks __has_attribute and friends, among other things. EOL for RHEL7 is 2024! And __has_builtin didn't even come around until GCC 10, and didn't work reliably prior to clang 11.
- loeg 7y ago
  4.x ran for nearly 12 years actually! April 2005 to 4.9.4 in December 2016. The 4.3.0 release was significant for at least two reasons: 1. True C99 "inline" support 2. Switch to the GPL3
  - klodolph 7y ago
    Counting time from 4-5, not time to last release in the 4 series.
    - loeg 7y ago
      Sure! It's a long time either way.
hadlock 7y ago
Postgres moved to this model somewhat recently. Two years ago we were talking about doing "the postgres 10 conversion" and now they're up to pg v. 12, or maybe higher already, I haven't checked. Semi-annual releases are nice, features ship when they are ready, and releases aren't delayed because that feature that's taking just a tiny bit longer than expected, well, it'll be fully baked by next year's release.

ktta 7y ago

They changed the way versioning is done around 3.9's release. http://blog.llvm.org/2016/12/llvms-new-versioning-scheme.html http://blog.llvm.org/2016/12/llvms-new-versioning-scheme.htm... I feel they are changing the version too quickly (I usually keep an eye out for the major version bumps, and with LLVM I just ignore them now)

eslaught 7y ago
Here's the HN discussion from when this was posted: https://news.ycombinator.com/item?id=13179903 https://news.ycombinator.com/item?id=13179903 Personally, though I agree the version number is going up too quickly, I appreciate that it at least aligns with their policy on breaking changes (which is to provide no hard guarantees on backwards compatibility).
loeg 7y ago
Ditto GCC after 4.x.[1] 4.0.0-4.9.4 (last) was Apr 2005 - Dec 2016. Almost 12 years. Starting in 5.x they dropped the 3rd release digit and started bumping the major version more frequently. Between Apr 2015 and the present, GCC has put out 5.x, 6.x, 7.x, 8.x, and 9.x. [1]: https://gcc.gnu.org/releases.html https://gcc.gnu.org/releases.html
aseipp 7y ago
Why would you ignore it because of that? LLVM's release cycle is short-ish, but its version bumps are precisely the kind you should pay attention to -- it's a project that changes rapidly with a large amount of features and many stakeholders. Breaks, as well as major new functionality, are common between releases. I don't see why the version today being 12 or 4.10 or whatever makes a difference to this. It's extremely worth keeping an eye on if you're invested in LLVM either way (as a user, downstream consumer, corporation, whatever.) This has been true since major corporate involvement started as long as 10 years ago or more... If anything, as another user mentioned, this version scheme is probably more honest to the way LLVM actually works anyway, because in practice every release has major breaking changes, and this scheme (in theory) better reflects that. At least with Firefox, most versions N and N+1 don't just visibly break tons of functionality for a user, so you could argue the increase is too rapid for what are (mostly) incremental changes. But LLVM's client base is much more vulnerable to major change and in practice it does break tons of APIs and make tons of changes release-to-release.

jpfr 7y ago

The same is happening with Firefox. Many "infrastructure" software projects have switched to time-based releases. Say, a release every 6 months. So there is no notion of big or small releases. Hence the seemingly fast increase of version numbers.

sdegutis 7y ago
It makes sense. Version numbers should be intuitive. Constantly changing software should update by whole numbers, so that the more it has changed, the more the number is different. Whereas "3.11" seems almost identical to "3.86" because they're both based on 3. Although I would argue that it should change by 0.5 per feature or something like that, so that if it has 10 new features the version number will be 5 higher, but only 2 new features will be 1 higher. Because Java has changed very little from 8 to 12, whereas Firefox's last 4 changes were altogether bigger.
asveikau 7y ago
You can still do a time based release without jumping major versions so often. Eg. OpenBSD's version number increments by 0.1 every six months and has done that for more than 20 years.

tveita 7y ago

Numba the Python library is only just getting around to support LLVM 9. https://github.com/numba/llvmlite/issues/523 https://github.com/numba/llvmlite/issues/523

klodolph 7y ago

2.x - 9 years 3.x - 4 years 4.x - 10 years Honestly, if nothing else, I hated seeing all the #if defined __GNUC__ && (__GNUC__ > 4 || __GNUC__ == 4 && __GNUC_MINOR__ >= 2)

wahern 7y ago
Fortunately these days you're supposed to use __has_attribute, __has_extension, and __has_builtin. But I'm not sure if, overall, things have gotten better. For example, overly eager diagnostic warnings have come at the cost of an increased need to disable diagnostics--perfectly standard-compliant code, not to mention widely supported extensions, will often trigger diagnostics with -Wall. You can disable those inline (and I try, because good luck trying to figure out what's the equivalent of CFLAGS in the build pipeline du jour, or simply expecting the user to figure it out), but they often have different names in different compilers and sometimes you have to resort to version guards to maintain a diagnostic-free build out-of-the-box. Also, the default compiler on RHEL7 is GCC 4.8, which lacks __has_attribute and friends, among other things. EOL for RHEL7 is 2024! And __has_builtin didn't even come around until GCC 10, and didn't work reliably prior to clang 11.
loeg 7y ago
4.x ran for nearly 12 years actually! April 2005 to 4.9.4 in December 2016. The 4.3.0 release was significant for at least two reasons: 1. True C99 "inline" support 2. Switch to the GPL3
- klodolph 7y ago
  Counting time from 4-5, not time to last release in the 4 series.
  - loeg 7y ago
    Sure! It's a long time either way.

hadlock 7y ago

Postgres moved to this model somewhat recently. Two years ago we were talking about doing "the postgres 10 conversion" and now they're up to pg v. 12, or maybe higher already, I haven't checked. Semi-annual releases are nice, features ship when they are ready, and releases aren't delayed because that feature that's taking just a tiny bit longer than expected, well, it'll be fully baked by next year's release.