Maybe they did something similar to what Gnome did when 2 was released?
ie. close all old bugs telling to test against the new version..
Maybe they did something similar to what Gnome did when 2 was released?
ie. close all old bugs telling to test against the new version..
The same problems apply for LLVM aswell, the reason 2.7's release has been pushed forward is due to release blockers, and just like gcc they have non-critical bugs hanging around from previous releases. It's just a fact with big complex projects, have you ever looked at a Microsoft Visual Studio service pack?
Awesome! way to go GCC guys, keep up the good work.
I was going to say haha april fools, but I see this was posted yesterday.
In any case that is not true, just look at bko.org, there are still many bugs with low numbers (i.e. pre 4.0) because some still apply to current trunk.
Exactly. You got it.
In fact it depends all on the maintainers how they handled it, but in KGet we closed any 3.5 bug as wontfix unless it still applies today.
Also wrong, acutally many projects were able to share lots of code and only rewrite small portions. Just look at KIO e.g. -- one of the core libs of KDE -- a lot of old code in there. And that says nothing about the quality.
It is possible that there were no "new" known bugs in the kde 3.5.10 release, since that was a relativly minor bugfix release. But it's ridiculous to claim that there aren't any older ones still hanging around. And LLVM/Clange/etc. are going to have the exact same thing happen to them. It happens to every major project out there, the only way to avoid it is to spend 5+ years frozen with no new features and only bugfixes, and if that were to ever happen people would just abandon the old project and create a fork that did take new features so that it wasn't falling so far behind the competition.
Exactly. You can stop and start fixing all the bugs, but world won't stop and wait for you to finish it. Ever.