[Libreoffice-qa] Win releases git repository
mikekaganski at hotmail.com
Mon Apr 3 07:11:44 UTC 2023
On 03.04.2023 9:55, Xisco Fauli wrote:
>> 2. I believe we can just have *major* releases, without point
>> releases. I.e., 18.104.22.168; 22.214.171.124; 126.96.36.199; 188.8.131.52; 184.108.40.206.beta1; ...
>> Because when we bibisect, we do it to do the following bisection in
>> the specific repo; so the branch point is the only interesting thing.
>> 220.127.116.11 is not useful for the bibisect; and avoiding these could
>> possibly keep some space.
> I disagree. It's based on
> https://downloadarchive.documentfoundation.org/libreoffice/old/, same as
> the release git repository for Linux. I believe if one version is in
> that page, it should also be in the git repository, even if it's a beta
> or RC.
Why? What is the upside of having them, and why "one version is in that
page" implies that it must be in a specific tool?
The extra versions there in the bisect repo are not only a bloat. They
actually destroy the ability to bisect sensibly: if you have the order like
then you have an older release from a different branch (3.3.4, Aug 2011)
in the same sequence and before an earlier release from the newer branch
(3.4.0, Jun 2011). The bisection repo of this form looses any value.
Indeed, simple chronological sequencing also has no sense.
The bibisect repo could itself have branches. But that would mean much
more work both when you create the repo, and when we use it (and no one
would need them: the releases bibisect repo is used to find some old
point, when there's no need to know if the regression had been also
backported to an older branch).
Overall, I believe that one release closest to the branch point is
enough, and is the only useful thing for such kind of bibisect.
And the downloadarchive has its own value, orthogonal to the discussed tool.
More information about the LibreOffice