4 ms·

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-

by 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.

by ktta 7y ago

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.