[Libreoffice-qa] Win releases git repository

[Mike Kaganski]

On 03.04.2023 9:55, Xisco Fauli wrote:
>> 2. I believe we can just have *major* releases, without point 
>> releases. I.e., 3.3.0.4; 3.4.0.1; 3.5.0.3; 3.6.0.4; 4.0.0.0.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. 
>> 3.3.1.2 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

   3.3.0
   3.3.1
   3.3.2
   3.3.3
   3.3.4
   3.4.0
   ...

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.

   3.3.0.4
   3.4.0.1
   3.5.0.3
   ...

And the downloadarchive has its own value, orthogonal to the discussed tool.


-- 
Best regards,
Mike Kaganski