Page 2 of 2 FirstFirst 12
Results 11 to 19 of 19

Thread: GCC 5.0 Is Expected Next Year

  1. #11
    Join Date
    Sep 2009
    Posts
    62

    Default

    Quote Originally Posted by Brane215 View Post
    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.

  2. #12
    Join Date
    Jul 2012
    Posts
    147

    Default

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

  3. #13
    Join Date
    Oct 2013
    Posts
    269

    Default

    Quote Originally Posted by Luke_Wolf View Post
    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?

  4. #14
    Join Date
    Feb 2011
    Posts
    1,224

    Default

    Quote Originally Posted by Marc Driftmeyer View Post
    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.

  5. #15
    Join Date
    Jun 2012
    Posts
    355

    Default

    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)

  6. #16
    Join Date
    Aug 2012
    Posts
    40

    Default

    Quote Originally Posted by Luke_Wolf View Post
    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.

  7. #17
    Join Date
    Sep 2009
    Posts
    62

    Default

    Quote Originally Posted by hubicka View Post
    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

  8. #18
    Join Date
    Jun 2011
    Posts
    1,028

    Default

    Quote Originally Posted by hubicka View Post
    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.

  9. #19
    Join Date
    Oct 2010
    Posts
    319

    Default

    Quote Originally Posted by hubicka View Post
    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.

    Quote Originally Posted by hubicka View Post
    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.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •