Weekly edition	Kernel	Security	Distributions	Contact Us	Search
Archives	Calendar	Subscribe	Write for LWN	LWN.net FAQ	Sponsors

a question

Posted May 3, 2007 9:54 UTC (Thu) by ekj (guest, #1524)
In reply to: a question by mmarkov
Parent article: A tale of two release cycles

A regression is a subclass of bug. All regressions are bugs, but not all bugs are regressions.

A regression is when something fails to work that used to work previously.

That is bad -- because it causes stuff that used to work to stop working, which annoys users.

It's usually less bad to ship a program with something non-working that *never* worked. Sure it's a bug, but if the users where OK with the last version of the program, they'll be ok with this one too.

(Log in to post comments)

regression vs bug

Posted May 3, 2007 17:40 UTC (Thu) by giraffedata (subscriber, #1954) [Link]

To be precise, you have to call what we're discussing here a "regression bug." Because there are regressions that are not bugs. A bug is where the product does not work as designed. Sometimes you design a release to lack functions the previous release had, so the release contains a regression, but not a bug.

Design regressions cause all the same damage as regression bugs (breaks expectations, causes people not to "upgrade"), but the process for eliminating them is entirely different.

BTW, "regression" is from the Latin for "to step back."

regression vs bug

Posted May 4, 2007 17:48 UTC (Fri) by i3839 (guest, #31386) [Link]

To give another kind of non-bug regressions:

A performance degradation is a regression too, while it's not always caused by a bug. So nothing stopped working, something just worked less well than it used to.