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
