4 ms·

Somehow I never realized that GCC has a very regular release schedule until looking it up just now: https://gcc.gnu.org/develop.html https://gcc.gnu.org/develop

by t-3 6mo ago

Somehow I never realized that GCC has a very regular release schedule until looking it up just now: https://gcc.gnu.org/develop.html https://gcc.gnu.org/develop.html

tosti 6mo ago
IIRC, since GCC got covered by GPL3. It used to be slower and I've spent way too much time working around C++ bugs in GCC 2.95 (The fact that I remember the problematic version is telling :)
- gpderetta 6mo ago
  Everybody remembers that specific version :). And I wasn't even programming professionally at that time!
  - bluGill 6mo ago
    For many years that was the only version that could be used. What become gcc3 took years. In the end it was better, but for a while gcc 2.95 was the best we had despite the bugs.
    - kjs3 6mo ago
      Oof...I know of at least 1 embedded shop still using 2.95.4 for various 'reasons'.
  - pjmlp 6mo ago
    Ah the egcs drama.
- physicsguy 6mo ago
  They changed their major release numbers too tbf. 4.x it was point release per year, now it's a major release per year.
r2vcap 6mo ago
Yeah, GCC’s recent major releases have been remarkably regular, much like Fedora’s spring releases, and their releases seem to fit into the same broader rhythm. Hint? Red Hat.
uyjulian 6mo ago
It has been that way since people from Cygnus (now RedHat->IBM) reorganized the project
- not2b 6mo ago
  That is why egcs was launched, to get around the inability of the old team to do gcc releases. The issues had little to do with ideology and were about fixing a broken process and replacing it with something that had a hope of working.
bluGill 6mo ago
Large projects have been going to regular scheduled releases for a long time. Until the 90's people thought they could waterfall a large release with all your desired features (and for tiny projects this is still a good idea), but as your projects grow (possibly just to small) you reach a point where someone is always working on a feature that isn't ready yet, so a regular release means you still can support your customers with releases. This forces developers who are unsure they will be ready to have some sort of "disabled this unstable feature" toggle, which is about the best you can do.
- cogman10 6mo ago
  Yup. OpenJDK is one of the best success stories of this. Up until Java 9, they would release once features were complete. But that meant there were years between the 7 and 8 release and even more years between the 8 and 9 release. The industry had gotten into the habit of always running old versions of Java (my company was on 6 for an uncomfortable amount of time. But others have had it worse). More frequent smaller releases has gotten companies more into the habit of updating frequently which also, very helpfully, gives devs new features frequently.
  - jabl 6mo ago
    The Linux kernel is another example. The 2.5 development cycle (which led to the stable 2.6 series) was brutally long, and distros resorted to back-porting new features into their own kernels based on the stable 2.4 series that they provided to their users, creating all kinds of excitement. After 2.6.0 was released, Linus basically went nope, not gonna do that again.
    - bluGill 6mo ago
      Are there any large projects that are older than 25 years that didn't go through that? The time based release thing as been recommended for about 25 years (can anyone get real data?), so newer projects may just be using it without knowing the pain, but for older projects it seems like they all went through it at least once.

by t-3 6mo ago

Somehow I never realized that GCC has a very regular release schedule until looking it up just now: https://gcc.gnu.org/develop.html https://gcc.gnu.org/develop.html

tosti 6mo ago

IIRC, since GCC got covered by GPL3. It used to be slower and I've spent way too much time working around C++ bugs in GCC 2.95 (The fact that I remember the problematic version is telling :)

gpderetta 6mo ago
Everybody remembers that specific version :). And I wasn't even programming professionally at that time!
- bluGill 6mo ago
  For many years that was the only version that could be used. What become gcc3 took years. In the end it was better, but for a while gcc 2.95 was the best we had despite the bugs.
  - kjs3 6mo ago
    Oof...I know of at least 1 embedded shop still using 2.95.4 for various 'reasons'.
- pjmlp 6mo ago
  Ah the egcs drama.
physicsguy 6mo ago
They changed their major release numbers too tbf. 4.x it was point release per year, now it's a major release per year.

r2vcap 6mo ago

Yeah, GCC’s recent major releases have been remarkably regular, much like Fedora’s spring releases, and their releases seem to fit into the same broader rhythm. Hint? Red Hat.

uyjulian 6mo ago

It has been that way since people from Cygnus (now RedHat->IBM) reorganized the project

not2b 6mo ago
That is why egcs was launched, to get around the inability of the old team to do gcc releases. The issues had little to do with ideology and were about fixing a broken process and replacing it with something that had a hope of working.

bluGill 6mo ago

Large projects have been going to regular scheduled releases for a long time. Until the 90's people thought they could waterfall a large release with all your desired features (and for tiny projects this is still a good idea), but as your projects grow (possibly just to small) you reach a point where someone is always working on a feature that isn't ready yet, so a regular release means you still can support your customers with releases. This forces developers who are unsure they will be ready to have some sort of "disabled this unstable feature" toggle, which is about the best you can do.

cogman10 6mo ago
Yup. OpenJDK is one of the best success stories of this. Up until Java 9, they would release once features were complete. But that meant there were years between the 7 and 8 release and even more years between the 8 and 9 release. The industry had gotten into the habit of always running old versions of Java (my company was on 6 for an uncomfortable amount of time. But others have had it worse). More frequent smaller releases has gotten companies more into the habit of updating frequently which also, very helpfully, gives devs new features frequently.
- jabl 6mo ago
  The Linux kernel is another example. The 2.5 development cycle (which led to the stable 2.6 series) was brutally long, and distros resorted to back-porting new features into their own kernels based on the stable 2.4 series that they provided to their users, creating all kinds of excitement. After 2.6.0 was released, Linus basically went nope, not gonna do that again.
  - bluGill 6mo ago
    Are there any large projects that are older than 25 years that didn't go through that? The time based release thing as been recommended for about 25 years (can anyone get real data?), so newer projects may just be using it without knowing the pain, but for older projects it seems like they all went through it at least once.