@Mal,
It is really rather simple, with a code base of several million lines,
isolating the source of a regression or anti-feature becomes important both
in triaging an issue and especially for isolating the problem in source
code. That point of first introduction comes with the earliest build -- not
the most recent release.
Every commit to LibreOffice and the OOo source before that is recorded--and
it is possible both to review exact changes that cause a problem--the
challenge is isolating the issue.
From a QA/triage perspective knowing the release build (or the daily build
for contemporary work in the master branch) lets us dig deeper into the
code. When we can include a fully bisected description -- i.e. prior to
this commit it was fine, after this commit it has gone bad -- the developers
have more incentive and a much better chance of locating the exact issue,
and then deciding on cost of fixing it.
The fix could be a single conversion factor, or could be hundreds of lines
of refactored source code--some things are trivial, some things are not
justified. But before that can be determined the cause has to be
isolated--and that can only be done at the earliest occurrence.
One of the reasons the project keeps the archive of prior releases available
for folks to install in parallel and test--knowing the earliest occurrence
is key.
Stuart
=-refs-=
http://downloadarchive.documentfoundation.org/libreoffice/old/
https://wiki.documentfoundation.org/Installing_in_parallel
![[TEST] Document Foundation Community](https://communitytest.documentfoundation.org/images/discourse-logo-sketch.png){kind=logo}