Sometimes, a bug (or security) fix introduces another bug. Also, minor feature enhancements happen even in stabilization mode. They are not supposed to cause issues (risky ones are done in development branch). But sometimes, some things slip through. These are high priority because people won't want to upgrade (vs a bug which has always been there).
Please see: How to figure out which commit causes a bug
Why it's important not to mislabel
Regressions are treated as higher priority than "normal" bugs because
- they are usually easier to fix
- not fixing them soon can lead to technical debt. We may then have more conditions to account for, and thus, more complexity, like at https://gitlab.com/tikiwiki/tiki/-/merge_requests/3221
- regressions reduce the number of people that upgrade and hold people back from using and contributing to new versions (documentation, testing new features, etc.)
Because regressions get enhanced attention, it is tempting to label something as a regression when it isn't.
This behavior is bad for the Tiki community. Please don't do it. Here is why:
- For reasons explained above, regressions are treated with higher priority
- All things being equal a developer can fix more regression bugs than "normal bugs". If you falsely steer developers away from real regressions, you increase the number of bugs in Tiki
- When an issue is a regression, the process is often different than a regular bug.
- We can use How to figure out which commit causes a bug, and thus find out the reason of the commit, and reduce the odds of breaking something that was worked on. If in fact it was not a regression, you made a developer waste their time
- We have sites which help us compare before and after
Related
- All Regressions
- Regressions
- Regressions in 10x
- Regressions in 11x
- Regressions in 12x
- Regressions in 25x
- Regressions in 26x
- Regressions in 27.x
- Regressions in 8x
- Regressions in 9x
- Regressions-in-28.x