GCC 5.0 Is Expected Next Year

[discordian]

Who cares how do they mark their releases.

As long as they work.

If you have a running system and your product has to meet strict safety standards then everything you change has to be argued and (re-)tested.
Now consider this if you want to change from version 5.1.3 to a version 5.1.4, on a project you know after years of using their product they take regressions seriously and only fix those (in a rather carfeul way not to break anything) in minor point releases. Its something you can setup as general rule that such minor point releases are worthy candidates to checkout and spend time testing.
If its just release 2014.7 or whatever they call it then you can start digging through changelogs and weighting the improvements vs risks before even considering talking to some project leader who has no deep knowledge compared to more specialized personal but has to make the decisions. Its something rather hard to put in a guideline, if the project itself bases its version on PR (bigger = better) than being more "open and directy" about compatibility and type of changes.

I doubt anyone still argues that Firefox and Chrome Numbering scheme has any other use than display how useless it is.

[Brane215]

Fine, but that is trivial problem, compared to problem of code quality.

IOW I hope this is not some attempt to get more attention without honest work on code.

Or some stupid projection that in two years LLVM might overtake them with version number...

[BSDude]

Just what exactly is illogical about the traditional:
x.y.z
where
X = a release that breaks the (API|ABI)
Y= a feature release that does not break the (API|ABI)
Z = a bugfix release

Fill in API or ABI depending upon how strict the project is on the matter.

This.

I'm curious, does LLVM break ABI compat everytime a dot release comes out?

[TheBlackCat]

1, 2, 3, 4, 5, etc., always represents major product advances/design changes.

.1,.2,...,.10,.11, etc., always represented minor improvements and bug fixes.

.x.y always meant bug fix releases only. [5.1.1,5.49.1, etc.]

No, it doesn't "always" mean that. That is but one of probably dozens of conventions used by different software projects. As others have pointed out, the Linux kernel does not follow that convention and never has.

[gamerk2]

The traditional x.y.z format:

x: Major Release (New features, graphical redesign, new platform support, etc)
y: Minor Release (New features with narrow scope, code/performance optimization, etc)
z: Bugfix (Bugfixes)

[hubicka]

Just what exactly is illogical about the traditional:
x.y.z
where
X = a release that breaks the (API|ABI)
Y= a feature release that does not break the (API|ABI)
Z = a bugfix release

Fill in API or ABI depending upon how strict the project is on the matter.

The problem of x.z.y scheme with GCC is that project has grown up too big for that. There are too many APIs/ABIs that are developed in not synchronized manner. Individual components are getting major changes in them, but that does not happen synchronously to justify overall rewrite of the project.

Next release will have new C++ ABI out that justify the major version change, but about every version does have such changes in it. There are also major changes that take more than one major release to happen (such as ongoing reorg to C++ ABIs and better modularity, or work on LTO that landed in 4.5 but became really useful in 4.8+ while it still have some rough edges today). Long discussions what changes are or are not important enough for major version bump does not leave more time for coding.

[discordian]

The problem of x.z.y scheme with GCC is that project has grown up too big for that. There are too many APIs/ABIs that are developed in not synchronized manner. Individual components are getting major changes in them, but that does not happen synchronously to justify overall rewrite of the project.

Next release will have new C++ ABI out that justify the major version change, but about every version does have such changes in it. There are also major changes that take more than one major release to happen (such as ongoing reorg to C++ ABIs and better modularity, or work on LTO that landed in 4.5 but became really useful in 4.8+ while it still have some rough edges today). Long discussions what changes are or are not important enough for major version bump does not leave more time for coding.

If you read my post, then you might understand that the long discussions will them be held by multiple groups that really depend on some sort of estimate of "friction" between different versions. and those groups are less capable at doing such estimates than the devs.

You are right with the versioning trouble, but abandoning them is just giving up. why even care with a two or 3 digit number then, just use wall-clock or git hashes - even less trouble.

Some things which are valuable for several industries and why gcc is used instead of llvm (at least for releases), is its proven track (huge amount of software is developer with or tested against it) and rather conservative minor-point releases. In other word it moves somewhat slower but doesnt leave you surprised after upgrades the way other compiler do. The known and familiar version scheme is actually part of that.

All IMHO, I guess I cant be fully objective if it will directly will cause me trouble

[Luke_Wolf]

The problem of x.z.y scheme with GCC is that project has grown up too big for that. There are too many APIs/ABIs that are developed in not synchronized manner. Individual components are getting major changes in them, but that does not happen synchronously to justify overall rewrite of the project.

Next release will have new C++ ABI out that justify the major version change, but about every version does have such changes in it. There are also major changes that take more than one major release to happen (such as ongoing reorg to C++ ABIs and better modularity, or work on LTO that landed in 4.5 but became really useful in 4.8+ while it still have some rough edges today). Long discussions what changes are or are not important enough for major version bump does not leave more time for coding.

All that really means is an inappropriately designed release/project structure that needs to be refactored into it's component parts, such that the corelib is separated out from the applications that use it, which will then have separate versioning, much the way KDE SC is now broken up into 3 separate logical parts: Corelib, Applications, and Shells.

[Ansla]

Next release will have new C++ ABI out that justify the major version change, but about every version does have such changes in it.

By ABI changes you mean adding new functionality in a backwards compatible way? Otherwise, gcc did not break the C++ ABI since the 3.4 release. And yes, that breakage happened between minor releases, not major like the theory says.

There are also major changes that take more than one major release to happen (such as ongoing reorg to C++ ABIs and better modularity, or work on LTO that landed in 4.5 but became really useful in 4.8+ while it still have some rough edges today). Long discussions what changes are or are not important enough for major version bump does not leave more time for coding.

What "ongoing reorg to C++ ABIs" are you talking about? And LTO should not do any changes to the ABI, if it does it's a bug.