Announcement

Collapse
No announcement yet.

GCC 5.0 Is Expected Next Year

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • GCC 5.0 Is Expected Next Year

    Phoronix: GCC 5.0 Is Expected Next Year

    GNU Compiler Collection developers are beginning to come to a consensus that GCC 5.0 will be released in 2015...

    http://www.phoronix.com/vr.php?view=MTc0NjI

  • #2
    Where does this crazy version hysteria come from? In the good old days it was version and revision mostly. These days it seems everyone is just trying to reach the highest version number possible. A high version number does not mean that a product is more mature at all. I would much rather have V1.49 because that means someone have revised the darn thing 49 times instead of version 7.2, 8.1, 9.3.
    When one bump a version it used to mean that the entire program was usually rewritten (a version for those who missed that). When you bump a revision it normally means you changed an existing program and usually added new features to it.
    ....I am surprised no one have started using unix timestamps as their version number. ...sigh...

    Comment


    • #3
      Originally posted by waxhead View Post
      Where does this crazy version hysteria come from? In the good old days it was version and revision mostly. These days it seems everyone is just trying to reach the highest version number possible. A high version number does not mean that a product is more mature at all. I would much rather have V1.49 because that means someone have revised the darn thing 49 times instead of version 7.2, 8.1, 9.3.
      When one bump a version it used to mean that the entire program was usually rewritten (a version for those who missed that). When you bump a revision it normally means you changed an existing program and usually added new features to it.
      ....I am surprised no one have started using unix timestamps as their version number. ...sigh...
      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.]

      Comment


      • #4
        Originally posted by waxhead View Post
        Where does this crazy version hysteria come from?
        I agree for some projects (like Chrome and Firefox), but for a project that's been around for almost 30 years, complaining about version 5.x seems a bit odd...

        Comment


        • #5
          Originally posted by DanL View Post
          I agree for some projects (like Chrome and Firefox), but for a project that's been around for almost 30 years, complaining about version 5.x seems a bit odd...
          Not really. If you remember, Linux changed their entire version-number structure starting with the 3.0 release. One could argue that it's both better and worse, but I tend to not get caught up in stuff like that.

          Comment


          • #6
            Originally posted by DanL View Post
            I agree for some projects (like Chrome and Firefox), but for a project that's been around for almost 30 years, complaining about version 5.x seems a bit odd...
            I would assume he is objecting to the idea of 6.0 in 2016, 7.0 in 2017, etc. Which would be stupid and pointless.

            Comment


            • #7
              Originally posted by carewolf View Post
              I would assume he is objecting to the idea of 6.0 in 2016, 7.0 in 2017, etc. Which would be stupid and pointless.
              Indeed, it would be much better if they adopted a more logical scheme, such as 14.07 (July 2014), 15.01 (January 2015), etc. Ubuntu got this right - do you see anyone complaining about their version numbers?

              Comment


              • #8
                Originally posted by BlackStar View Post
                Indeed, it would be much better if they adopted a more logical scheme, such as 14.07 (July 2014), 15.01 (January 2015), etc. Ubuntu got this right - do you see anyone complaining about their version numbers?
                Ubuntu is a distro not a specific application or library. Distro versions are always very abstract as everything they consist of upgrade at different speeds. GCC on the other hand, is an application and library, they do have real information to communicate with a version number. Using a pointless uninformative number would make their versions less informative for absolutely no gain.

                Comment


                • #9
                  Originally posted by BlackStar View Post
                  Indeed, it would be much better if they adopted a more logical scheme, such as 14.07 (July 2014), 15.01 (January 2015), etc. Ubuntu got this right - do you see anyone complaining about their version numbers?
                  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.

                  Comment


                  • #10
                    Why is this even an article ?

                    Who cares how do they mark their releases.

                    As long as they work.

                    Comment


                    • #11
                      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.

                      Comment


                      • #12
                        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...

                        Comment


                        • #13
                          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?

                          Comment


                          • #14
                            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.

                            Comment


                            • #15
                              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)

                              Comment

                              Working...
                              X